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Előszó 


Ez a jegyzet a Széchenyi István Egyetem másodéves villamos- 
mérnök BSc hallgatóinak oktatott Számítógép-hálózatok tárgy- 
hoz készült. A tárgy egyrészt az összes villamosmérnöki szak- 
irány számára nyújt alapvető ismereteket a számítógép-háló- 
zatokról, másrészt fontos alapot jelent a távközlés-informatika 
szakirány" több tárgya (Protokollok és szoftverek, Hálózati ope- 
rációs rendszerek, Kommunikációs rendszerek programozása és 
Hálózatok biztonsága) számára. 

A jegyzet először a szükséges alapismereteket tárgyalja. Ez- 
után részletesen foglalkozik a legfontosabb lokális hálózati meg- 
oldásokkal (Ethernet és vezetéknélküli hálózatok különböző faj- 
tái), majd az internet protokollkészlettel és az útvonalválasztás- 
sal. Betekintés szintjén bemutatja a legfontosabb hálózati alkal- 
mazásokat és a TCP/IP socket interface programozását. Végül 
egy rövid összefoglalást ad a számítógép-hálózatok teljesítőké- 
pesség-vizsgálatára alkalmazható eljárásokról és az eredmények 
megjelenítésének módszereiről, trükkjeiről. A függelékben talál- 
ható egy rövid Unix összefoglaló, amivel a tárgy laborgyakor- 
latain használt Linux operációs rendszer kezeléséhez kívánunk 
segítséget nyújtani a hallgatóink számára. 





A szakirányt csak a nappali tagozatos hallgatóink számára hirdetjük 
meg. 


Az érdeklődő olvasók az egyes témaköröknél bőségesen ta- 
lálnak hivatkozásokat olyan művekre, melyek az adott téma- 
kört részletesebben tárgyalják. Ezek között szerepelnek magyar 
nyelvűek is, de a többségük angol nyelvű. Erősen bátorítjuk a 
hallgatóinkat az angol nyelvű szakirodalom olvasásának gyakor- 
lására, mert mérnökként a megoldandó feladataikhoz sok eset- 
ben csak angol nyelvű szakirodalom áll majd rendelkezésükre. 

Ha valaki hibát fedez fel ebben a jegyzetben, akkor azt a 
távközlés-informatika szakirány honlapján [20] a tárgynál meg- 
található módon tudja bejelenteni." Ugyanott megtalálható az 
aktuális hibajegyzék elérhetősége is. 

Jelen kiadás a 2007. évi első kiadás javított változata. Kö- 
szönetemet fejezem ki mindazoknak, akik a hibákat bejelentet- 
ték, és ezzel hozzájárultak a jegyzet minőségének javításához. 


Lencse Gábor 


?A tárgy hallgatói az elsőként bejelentett hibákért valamilyen jutalma- 
zásban részesülnek, ennek módját és mértékét félévenként állapítjuk meg. 


VI 


1. fejezet 


Bevezetés 


E jegyzet terjedelme nem teszi lehetővé, hogy a számítógép- 
hálózatok létrejöttének történetével, fejlődésével részletesen fog- 
lalkozzunk." Először definiáljuk, hogy mit tekintünk számító- 
gép-hálózatnak, majd megvizsgáljuk, mi is a célja, feladata. 

Definíció: A számítógép-hálózat autonóm (önálló mű- 
ködésre képes) számítógépek összekapcsolt (információcserére 
képes) rendszere.? 

De miért használunk számítógép-hálózatokat, mi a számító- 
gép-hálózat célja, feladata ? 


kommunikáció ember-ember között, például: e-mail, IP tele- 
fon, hírcsoportok, stb. 


erőforrás-megosztás - például adatok, háttértár, processzor, 
memória, perifériák megosztása más számítógépek, illetve 
azok felhasználói számára 





"Ebben a fejezetben főleg az irodalomjegyzékben található [17] könyvre 
támaszkodunk, amit - mint a témában alapművet - minden érdeklődő 
számára ajánlunk. 

Ma már ennél szélesebb értelemben is használjuk. 
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nagy megbízhatóság erőforrás többszörözéssel, akár külön- 
böző telephelyeken (például számítási kapacitás többszö- 
rözése vagy adatbázisok replikálása katasztrófa elleni vé- 
dekezésre) 


költséghatékonyság feladatszétosztással: szuperszámítógép 
helyett munkaállomások csoportja (lényegesen olcsóbban 
elérhető a kívánt számítási kapacitás, természetesen csak 
bizonyos feladatosztályra hatékony) 


Hogyan valósíthatók meg ezek a célok és más hasonlók? Ez 
sajnos nem tartozik vizsgálódásunk körébe, a fenti alkalmazá- 
sok viszont kellő motivációt nyújtanak a számukra nélkülözhe- 
tetlen számítógép-hálózatok alapos megismerésére. 


1.1. . Alapfogalmak 


Nemsokára látni fogjuk, hogy nem kevés feladatot kell megol- 
danunk ahhoz, hogy két egymástól távoli számítógép kommu- 
nikálni tudjon egymással. A tervezési bonyolultság csökkentése 
érdekében a megoldandó feladatot rétegekre bontással struktu- 
rálhatjuk. Ezek a rétegek egymásra épülő szinteket jelentenek. 
Egy réteg az alatta levő (egyszerűbb feladatot megoldó) réteg 
szolgáltatásait felhasználva annál bonyolultabb, , értéknövelt" 
szolgáltatást nyújt a felette levő rétegnek. Egy adott réteg 
vizsgálatakor az alatta levő rétegeket fekete doboznak tekint- 
hetjük: nem foglalkozunk azzal, hogy milyen a belső működése, 
számunkra csak az érdekes, hogy hogyan viselkedik. 

A hálózat valamely rétege, mint fekete doboz az 1.l. áb- 
rán látható. A rajz két oldalán található , A" és , B" entitások, 


" Érdeklődő hallgatóink a tfávközlés-informatika szakirányon választ kap- 
hatnak erre a kérdésre. 
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protokoll 
Fall ii" seg . 7 tex e ag je 
CA (B) 
Mk Sz sz st ke. 8 s B aj ? 
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jő Bal 
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LL m—— me ———egöngi e m- —msil; 











1.1. ábra. A fekete doboz modell 


vagy processzek egymással kommunikálni akarnak. Az ,A" ké- 
rést4 intéz az alsóbb réteghez, amely számára fekete dobozként 
látszik, eltakarva a belső működését. A kérést ez a réteg va- 
lamilyen formában eljuttatja ,,B"-hez (bejelentés). ,,B" egy vá- 
laszt küld szintén az alsóbb réteget használva, mely , A" felé egy 
megerősítést továbbít. Példánkban ,A" kommunikált ,,B"-vel. A 
kommunikáció , nyelve" a protokoll, amelyet mindkét entitás ért. 
Fizikailag azonban nem egymással , beszélnek", hiszen nem , lát- 
ják" egymást, hanem mindketten az alsóbb szintet kérik meg a 
kommunikáció lebonyolítására. A fekete doboz belseje hasonló- 
képpen épül fel, benne két újabb entitás található, valamilyen 


kérés, bejelentés, válasz, megerősítés: az 1.2 alfejezetben tárgyalt OSI 
modell kifejezései. 
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b. 


(a fentitől eltérő) nyelvvel, amelyet mindketten értenek, és az 
interfészek segítségével ismét egy alsóbb rétegen keresztül jut 
át az információ. 

Definiáljuk most formálisan is az új fogalmakat: 

Definíció: Az entitás (vagy más kifejezéssel: processz) az 
egyes rétegekben lévő aktív cselekvő. Az azonos rétegben lévő 
entitásokat társentitásoknak (peer entities) nevezzük. 

Definíció: A protokoll a különböző gépeken futó n-edik 
szintű (— n-edik rétegben elhelyezkedő) entitások (vagy pro- 
cesszek) egymással való kommunikációja során használt szabá- 
lyok és konvenciók összessége. 

Definíció: A szolgáltatás elemi műveletek (primitívek) hal- 
mazával írható le, amelyek a szolgáltatást elérhetővé teszik a 
felhasználó vagy más entitások számára. 

Definíció: Az interfész az adott réteg által az eggyel felette 
lévő réteg számára biztosított elemi műveletek és szolgáltatások 
összessége. 

Definíció: A hálózat architektúrája rétegeket és proto- 
kollokat tartalmaz. 

A hálózati architektúra a definíció szerint nem tartalmazza 
az interfészeket. A következő példánkban szemléletesen látszik, 
hogy azonos architektúrák, de eltérő interfészek használata ese- 
tén működik a kommunikáció. Az ,A" entitásunk most legyen 
egy süketnéma ember, a , B" entitás pedig egy vak és béna em- 
ber. Az alkalmazott interfészek tehát eltérőek lesznek, az el- 
sőnél monitor és billentyűzet, míg a másodiknál fejhallgató és 
mikrofon. Mivel azonban mindketten magyarul beszélnek, meg 
fogják érteni egymást, feltéve, hogy (például) a , B" gépén egy 
program az , A" levelét felolvassa, és a , B" beszédét ASCII szö- 
veggé alakítva az , A"-nak elküldi. 

Vizsgáljuk meg a rétegek közötti kapcsolatokat általánosan! 
Az 1.2. ábrán három réteg látható. (Az azonos szinten lévő 
entitások között kellően nagy fizikai távolság is lehet, például 
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1.2. ábra. Rétegek közötti kapcsolat 


Az 1.2. ábra rövidítései: 
e Ent. - Entity (entitás) 
. SAP - Service Access Point (szolgáltatás elérési pont) 
" PDU - Protocol Data Unit (protokoll adategység) 


e PCI - Protocol Control Information (protokoll vezérlési 
információ) 


" SDU - Service Data Unit (szolgáltatás adategység) 


Magyarország - USA.) Az N-edik szinten az entitások egymás- 
sal az iV-edik szintű protokollal kommunikálnak logikailag. Fi- 
zikailag az alattuk lévő N — 1-edik rétegtől az N — 1-edik szintű 
interfész megfelelő szolgáltatás elérési pontján (SAP) keresztül 
kérnek szolgáltatásokat. Az N — 1-edik réteg szolgáltatás elérési 
pontjai között NM — 1-edik szintű kapcsolat jön létre. Az ábra 
jobb oldalán az N-edik rétegben láthatjuk az N-edik réteg pro- 
tokoll adategységét (PDU), mely két részből, a fejrészből (PCI) 
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és a szolgáltatás adategységéből (SDU) tevődik össze. A PCI 
gyakorlatilag a szolgálati közlemény az N-edik szintű társenti- 
tás (peer entity) számára, az SDU pedig az átvinni kívánt adat, 
amit az N-edik szintű entitás az N - 1-edik rétegtől kapott. Az 
egyes rétegek tehát mindig hozzáteszik a saját vezérlési informá- 
ciójukat a felettük lévő rétegtől kapott információhoz mintegy 
beágyazva, (packing) az elküldendő adatot, míg a másik oldalon 
felfelé haladva pedig kibontás (unpacking) történik, aminek az 
eredménye a korábban becsomagolt információ lesz. 

Természetesen a rétegek száma mindig véges, vagyis a leg- 
alsó rétegben már nem vesszük igénybe egy újabb réteg közre- 
működését, hanem valamilyen módon megtörténik az informá- 
ció átvitele. A rétegek száma tervezői döntés. 


1.2. Az OSI és a TCP/IP referenciamodell 


Az OSI hivatkozási modell az 1.3. ábrán látható. Ez a mo- 
dell a Nemzetközi Szabványügyi Szervezet (ISO - International 
Organization for Standardization) ajánlása. Ezt a modellt hiva- 
talosan OSI (Open System Interconnection — nyílt rendszerek 
összekapcsolása) hivatkozási vagy referenciamodellnek nevezik, 
és egy olyan ajánlást definiál, amelynek megfelelő rendszerek 
egymással elvileg képesek együttműködni. Bár valóban létez- 
nek is OSI szerinti hálózatok, mi ezt csak referenciamodellként 
használjuk, azaz különböző hálózatok tárgyalásakor az egyes 
rétegekben definiált funkciókészletre a réteg nevével vagy szá- 
mával hivatkozunk. 

Most röviden összefoglaljuk az egyes rétegek feladatát (alul- 
ról felfele haladva). 


Fizikai réteg A fizikai réteg (physical layer) feladata az, hogy 
továbbítsa a biteket a kommunikációs csatornán. (Azaz a 


jA rétegeket alulról felfele 1-től 7-ig számozzuk. 


I.2. AZ OSI ÉS A TCP/IP REFERENCIAMODELL 7 


Xikalmazási protokoll 















































7. Alkalmazásíréleg  [d- 1 7. Application layer ! APDI 
FEzB re. éb SttERtáttt IEEE 
—— át ya ; k : si 
égy Megjelenítési protokoll Í 
6. Megjelenítési réteg B 6. Prescntation layer PPDU 
ENE, 7 4) t KERANÉÉ MNB 
sss 8 j CERN , JESSE a 
9 Viszonyi protakoll Bara íz; 
5. Viszony réteg az ÉNÉRE f- me) 5. Scssion layer SPDL 
7— L pe 
MESS. ZRME ES ú ee eb . TESZ ESB A 
Szállítási protokollt 
4. Szállítási réteg e -—-pei 4. Transport layer IPDI 
§ űl tj 
MERL ú G § 1 
Hálózati protokoll Í 
csomag 3. Hálózati réteg at venmzzzmzzmee mm ege 3. Network layer packet 
( ON j já 7 j 
Ld a rraezűsmetsizll enzegzűmenineűi 
9 Adatkapcsolati protokoll ú 
keret ! 2. Adatkapcsolati réteg [-g----- ree - - emel 2. Data link layer (rame 
e 1— e [ERR megememátj 
———— 1 d. 4 
ki , 8. hi Fizikai protokoll E 
hit, szimbólum ! 1. Fizikai réteg [Ha---- - TAMEEBENESEL ÉSÉT me! 1. Physical layer bit, symbol 
L meszi ———— ali SE 
szirt s ü ön 1 
Fizikai közes Physical medium 


1.3. ábra. OSI referenciamodell 


rétegnek biztosítania kell azt, hogy az egyik oldalon elkül- 
dött I-es bit a másik oldalon is 1-ként érkezzen meg, a 0 
értékű bit pedig 0-ként.) Ez a réteg tipikusan olyan kér- 
désekkel foglalkozik, hogy milyen átviteli közeget és mi- 
lyen csatlakozókat használjunk, milyen kódolásokat (mo- 
dulációt) alkalmazzunk (például: milyen feszültségszintet 
használjunk a logikai 1, és mekkorát a logikai 0 reprezen- 
tálásához), mennyi ideig tartson egy bit továbbítása, az 
átvitel megvalósítható-e egyszerre mindkét irányban, mi- 
ként jön létre és hogyan bomlik le az összeköttetés, ha 
már nincs szükség rá, stb. 

Az átvitel adategysége a bit vagy szimbólum. 


Adatkapcsolati réteg Az adatkapcsolati réteg (data link lay- 
er) legfontosabb feladata az, hogy a fizikai szint szolgál- 
tatásainak igénybevételével a hálózati réteg számára hi- 
báktól mentes átvitelt biztosítson szomszédos állomások 
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között. Ehhez az átviendő információt keretekbe (frame) 
szervezi (ezek tipikusan néhány száz vagy néhány ezer 
bájtból állnak), amelyek az adatokon kívül természete- 
sen , szolgálati közleményeket" (azaz a társentitásnak szóló 
vezérlő információt) is tartalmaznak (például melyik ál- 
lomás küldi melyik állomásnak, a címzettnek mit kell a 
kerettel tennie) ezeket a megfelelő sorrendben elküldi a 
célállomásnak, majd végül feldolgozza a vevő által vissza- 
küldött nyugtázó kereteket (aminek során esetleg néhány 
keretet újra kell adnia). 

A kommunikáció adategysége tehát a keret. 


Hálózati réteg A hálózati réteg (network layer) fő feladata 
az, hogy az adatkapcsolati réteg szomszédos állomások 
közötti átviteli képességére építve megoldja a csomagok 
eljuttatását a forrásgéptől a célgépig. A legfontosabb kér- 
dés itt az, hogy milyen útvonalon kell a csomagokat a 
forrásállomástól a célállomásig eljuttatni. A tforlódásvéde- 
lem (congestion control) megvalósítása is e réteg feladata. 
Ebben a rétegben az adategységet csomagnak nevezzük. 


Szállítási réteg A szállítási réteg (transport layer) legfonto- 
sabb feladata az, hogy kijavítsa a hálózati rétegben elő- 
forduló esetleges hibákat (például csomagvesztés, sorrend- 
csere), és így végponttól végpontig terjedő megbízható át- 
vitelt biztosítson. 

Ebben a rétegben (a fölötte levő rétegekhez hasonlóan) 
nincs külön speciális neve az adategységnek, egyszerűen 
csak szállítási szintű adategységnek nevezzük. 


Viszony réteg A viszony réteg (session layer) feladatára jó 
példa az ellenőrzési pontok alkalmazása. Nagy fájlok át- 
vitelekor a kapcsolat megszakadása esetén az utolsó ellen- 
őrzési ponttól folytatható az átvitel. 
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Megjelenítési réteg A megjelenítési réteg (presentation layer) 
tipikus feladata az adatok szabványos módon történő kó- 
dolása. Például ASCII, EBCDIC, Unicode; a különböző 
számábrázolások, stb. 


Alkalmazási réteg Az alkalmazási réteg (application layer) 
számos hálózati szolgáltatás protokollját tartalmazhatja, 
például: elektronikus levelezés, távoli bejelentkezés, kü- 
lönféle fájlátviteli és elérési protokollok. (Ezeket , látja" 
egy átlag felhasználó a hálózatból.) 


A továbbiakban az egyes rétegek feladatával részletesen meg 
fogunk ismerkedni. Azonban már a fenti rövid összefoglalásból 
is látszik, hogy némely rétegnek több, másiknak kevesebb fel- 
adata van. így természetesen a későbbiekben más-más súllyal 
fognak szerepelni az egyes rétegek. 

Most még annyit említünk meg, hogy az OSI modellben 
az adatkapcsolati rétegbe nagyon sok funkció került, ezért az 
IEEE 802 szabványban ezt a réteget két alrétegre bontották. 
Közülük az alsó a MAC (Media Access Control - közeghozzá- 
férés vezérlés), a felső az LLC (Logical Link Control - logikai 
kapcsolatvezérlés) alréteg. 


Hálózati réteg ga iz Y ? 
ke LLC Logical Link Control 





Adatkapcsolati réteg I s 








Fizikai réteg 5 MAC Media Access Control 


1.4. ábra. Az adatkapcsolati réteg alrétegei 


Az alrétegek az alábbiak szerint osztoznak az adatkapcsolati 
réteg feladatain: 
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" A MAC alréteg feladata meghatározni, hogy az adott 
pillanatban az állomások közül melyik adhat a csatornán. 


:" Az LLC alréteg feladata a forgalomszabályozás" (flow 
control), a hibajavító kódolás, a nyugtázás és (szükség 
esetén) az ismétléskérés. 


Az OSI modell a gyakorlatban nem terjedt el, helyette a 
TCP/IP modell kapta a nagyobb szerepet, de mint referencia- 
modell jól használható, mert szerepelnek benne a megvalósí- 
tandó funkciók, és hogy azok hol helyezkednek el, hogyan épül- 
nek egymásra. 


Az 1.5. ábrán jól láthatók a különbségek: a TCP/IP modell 
kevesebb réteget definiál, mint az OSI modell. 


A TCP/IP modell /P (angolul Internet Protocol, magya- 
rul internet protokoll) rétege megfelel az OSI modell hálózati 
rétegének, a TCP (TransmáÁssion Control Protocol - átvitel ve- 
zérlési protokoll) rétege pedig a szállítási rétegnek. A TCP/IP 
modellben a hordozó hálózat az OSI modell két alsó rétegének a 
funkcióját látja el. Teljesen hiányzik viszont a megjelenítési és 
a viszony rétegek megfelelője. Az alkalmazások természetesen 
tartalmazhatják ezeket a funkciókat, de nem feltétlenül talál- 
hatók meg bennük. (Például egy hagyományos f tp programnál 
megszakadás esetén kezdhetjük elölről a letöltést, de vannak 
olyan fájlletöltő programok, amelyek képesek folytatni a meg- 
szakadt letöltést.) 





" Egy lassabb állomásnak lehetősége van arra, hogy egy gyorsabb állomás 
neki szóló adását fékezze, és a gyorsabb állomás csak olyan sebességgel 
adjon, hogy a lassabb képes legyen feldolgozni. 
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OSI TCPAP 


Alkaltnazási réteg j Alkattazási réteg J 


Megjelenítési réteg 
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Viszony réteg 


fm 








Szállítási réteg (TCP) 


li 
j Internet réteg (IP) 
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Szállítási réteg 











Hálózati réteg 


]w Adatkapcsolati réteg 














Hordozó hálózat 


Fizikai réteg 





i 


1.5. ábra. OSI és a TCP/IP referenciamodellek összehasonlítása 


1.3. Hálózati topológiák 


Egy számítógép-hálózat fontos jellemzője annak topológiája. 
Attól függően, hogy az állomásainkat összekötő hálózat pont- 
pont kapcsolatokból áll, vagy üzenetszórásos csatornát tartal- 
maz, más-más topológiák lehetségesek. A pont-pont összekötte- 
tés azt jelenti, hogy minden hálózati csatorna pontosan két cso- 
móponthoz kapcsolódik, míg az üzenetszórásos csatorna esetén 
a csatornára (bizonyos határon belül) tetszőleges számú állomás 
kapcsolódhat. 





TA topológiát a matematikusok gumi geometriának is nevezik, mert csak 
az számít, hogy mely pontok mely pontokkal vannak összekötve, és nem 
foglalkozik azok tényleges elhelyezkedésével, a köztük levő távolságokkal. 
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1.3.1. Pont-pont összeköttetés esetén 


TR ZA 


Ötféle topológiát különböztetünk meg: csillag, fa, gyűrű, teljes 
és szabálytalan (1.6. ábra). 


8 T 9 1 . e A 
/ e ÉT a : -7g ki 
06 e A j S. XM € e n 

/ s 8. . b Bi [AAS AI d 
e [j sa ls 0-7. v/ Ja! 

e. § Ja v íj . é 

d . 
1 bh ) d) c 


72 e 


1.6. ábra.  Topológiák: a) csillag, b) fa, c) gyűrű, d) teljes, 
e) szabálytalan 


. A csillag topológiában egy központhoz (csillagpont) kap- 
csolódik az összes többi állomás. 


, A fa struktúra egy körmentes gráf, így bármely két pontja 
között csak egy útvonal létezik. 


" A gyűrű topológia gráfja egy körből áll, minden állomás- 
nak két szomszédja van. 


," A teljes gráf megoldásban minden állomás minden állo- 
mással közvetlenül össze van kötve. A kapcsolatok száma 
n csomópont esetén: nín — 1)/2. 


." Szabálytalannak nevezzük mindazt, ami az első négybe 
nem fér bele. (Természetesen részgráfként tartalmazhatja 
azok bármelyikét.) 


Az első négyet helyi hálózatoknál, a szabálytalant főleg nagy 
távolságok áthidalásánál alkalmazzák. 
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1.3.2. Többszörös hozzáférésű csatorna esetén 


TROT ZA 


A topológia lehet busz vagy gyűrű, illetve megkülönböztetjük a 
műholdas adatszórás topológiáját (1.7. ábra). 











a) b) c) 


TOT ZA 


1.7. ábra. Topológiák: a) busz, b) gyűrű, c) műholdas 


A busz rendszerben ha valaki ad, azt mindenki hallja. A 
busz végein hullámimpedanciával való lezárást kell alkal- 
mazni, hogy a jelek ne verődjenek vissza (mintha végtelen 
hosszú lenne a vezeték). 


A gyűrű megvalósítása pont-pont kapcsolatokból áll. Úgy 
lehet mégis üzenetszórásos csatornaként használni, hogy 
az állomások ismételnek, míg az információ vissza nem 
ér az adóhoz, és az eredeti adó vonja ki a gyűrűből. így 
minden állomáson keresztülhalad az információ, tehát le- 
hetőség van arra, hogy akár mind az összes, akár csak a 


címzett vegye azt, hasonlóan a busz topológiához. 


A műholdas rendszerben az állomások nem látják egy- 
mást (azaz közvetlenül nem képesek egymással kommu- 
nikálni, csak a műholdon keresztül), a műholdat a földi 
állomások egy bizonyos frekvencián szólítják meg, és az 
egy másik frekvencián válaszol nekik. 
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1.4. MAC protokollok 


Most megismerünk néhány MAC protokollt. Ezek közül né- 
melyeket olyan rendszerhez fejlesztettek ki, amelyet már nem 
használnak, de a történeti érdekességen túl azért is érdemes? 
mindegyiket alapötlet szintjén megismerni, mert a hálózatok 


fejlődésével ismét előállhat olyan helyzet, amikor alkalmazha- 
tók lesznek. 


1.4.1.  ALOHA 


Az ALOHA protokollt rádiós rendszerre tervezték.  Master- 
slave (mester-szolga) hierarchiában levő gépek közötti kommu- 
nikációt biztosít. A kitüntetett állomást (master) két csatorna 
köti össze a többi állomással (üzemi és nyugtázó). Egy slave 
bármikor adhat az üzemi csatornán, azonban ha egy másik slave 
egy időben adott vele, akkor ütközés lép fel. Ütközés esetén 
mindkét slave kerete elveszik akkor is, ha az átlapolódás csak 
részleges. Amennyiben a master helyesen vette az adást, nyug- 
tát küld a slave-nek. Mivel ezt a nyugtázó csatornán végzi, nem 
léphet fel ütközés (ugyanis ezen a csatornán csak a master ad- 
hat). Ha a slave nem kap nyugtát az elküldött keretről, akkor 
újra leadja azt, feltételezve, hogy az előző kerete ütközést szen- 
vedett és elveszett. Egy ilyen ütközést szemléltet az 1.8. ábra. 


hd 


A protokoll előírja az azonos kerethosszak használatát. 
Végtelen populációjú modell szerint, ha az igények Poisson 
eloszlásúak, a maximális kihasználtság legfeljebb 1893 lehet, 
lásd az 1I.14. ábrát a 19. oldalon. A görbén láthatjuk, hogy 
a kihasználtság egy határig nő, de aztán ahogy a próbálkozások 


"Ezen kívül didaktikailag is hasznosak: némelyik ismerete elősegíti a 
másik megismerését, valamint teljesebb képet nyerünk a lehetőségekről, ha 
olyan MAC protokollokkal is találkozunk, amelyeket a jelenleg elterjedtebb 
hálózatokban éppen nem alkalmaznak. 
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1.8. ábra. ALOHA keretek ütközése három állomás esetén 
(t — ütközés miatt elveszett idő) 











száma emelkedik, az áteresztőképesség egyre csökken. Ez termé- 
szetesen az ütközések egyre növekvő aránya miatt van Így. 


1.4.2. Réselt ALOHA 


Az ALOHA protokolljából nyerjük időrésekkel való kiegészítés- 
sel. Az üzemi csatornán egymással versengő slave állomások az 
időrés elején kezdhetnek adni. Az időrések kezdetét a master 
által kibocsátott szinkron jel jelzi. (Egy időrés természetesen 
valamennyivel hosszabb az egy keret leadásához szükséges idő- 
nél, ez véd a terjedési idő okozta gondokkal szemben.) Az idő- 
rések használata miatt az ütközések feljesek (1.9. ábra). így ha 
ütközés történik, akkor azzal 1 időrést veszítünk, szemben az 
ALOHA protokollal, ahol szerencsétlen esetben két keret ütkö- 
zése közel 2 keretidőnyi veszteséget okozhatott. A maximális 
kihasználtság így 3699-ra nőhet, lásd az 1.14. ábrát. 


1.4.3.  "CSMA 


d 4 


A CSMA-t (Carrier Sense Multiple Access — vivőérzékeléses 
többszörös hozzáférés) kábeles rendszerekben alkalmazzák. Itt 
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1.9. ábra. Réselt ALOHA keretek ütközése három állomás ese- 
tén (t — ütközés miatt elveszett idő) 


biztonsággal megoldható, hogy az állomások figyelik a csator- 
nát, és addig nem adnak, amíg az foglalt. A protokollnak több 
változata van. 

1-perzisztens CSMA 


Az , A" állomás belehallgat a csatornába. Ha foglalt, addig vár, 
míg a , B" állomás be nem fejezte a keretet (közben figyeli a 
csatornát), és utána azonnal adni kezdi a sajátját (1.10. ábra). 


B A 


A 


1.10. ábra. 1-perzisztens CSMA 


A módszer hátránya: ha a , B" állomás adása alatt az ,A" 
és a , C" állomás is adásra kész, amikor ,,B" befejezi az adását, 
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mind a kettő adni kezd; ekkor kereteik ütköznek és elvesznek 
(1.11. ábra). 





Al C 


1.11. ábra. Ütközés 1-perzisztens CSMA esetén 


Nemperzisztens CSMA 


Az ,A" állomás belehallgat a csatornába, mivel foglalt, 7 ideig 
vár, majd újra megvizsgálja, hogy szabad-e a csatorna. Ha 
szabad, akkor ad, ha nem, megint vár ?f ideig és újra próbálkozik 
(1.12. ábra). Ez abban az esetben előnyös, ha sokan akarnak 
adni, mert nagy valószínűséggel elkerülik azt, hogy egy keret 
befejeződésekor többen egyszerre adjanak. 


B A 
I I SEAN! VENNE] EBB 


bj a 


tl 





1.12. ábra. Nemperzisztens CSMA 
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p-perzisztens CSMA 


Az ,A" állomás belehallgat a csatornába, ha foglalt, addig vár, 
míg , B" állomás be nem fejezte a keretet, és utána p valószínű- 
séggel adni kezdi sajátját, illetve (1 — p) valószínűséggel í ideig 
vár, majd újra próbálkozik (0 x p . 1) (1.13. ábra). 


p valószínűséggel (1-p) valószínűséggel 


1.13. ábra. p-perzisztens CSMA 


CSMA változatok összehasonlítása 


Az 1.14. ábra azt sugallja, hogy minél kisebb a perzisztencia, 
annál jobb a csatornakihasználtság. Ez igaz is, de egy fontos 
tényről nem szabad megfeledkeznünk. A csatorna kihasznált- 
ság növelésének ára van. Ha a 0,01-perzisztens CSMA-t nézzük, 
ilyen nagy kihasználtság eléréséhez az kell, hogy egy adásra kész 
állomás csak 0,01 valószínűséggel kezdjen adni, miután a másik 
abbahagyta. Ennek az lesz a következménye, hogy az állomá- 
soknak igen sokáig kell várniuk! A kihasználtság magas, viszont 
a felhasználók sokat várakoznak. Összegzésként megállapíthat- 
juk tehát, hogy egyik protokollt sem nevezhetjük jobbnak a má- 
siknál, viszont a forgalom mértékétől függően egyik vagy másik 
hatékonyabb lehet. 
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1.14. ábra. Véletlen hozzáférésű protokollok összehasonlítása 
a terhelés függvényében mért csatornakihasználtság alapján 
(S — áteresztőképesség/keretidő, G — próbálkozások száma/ke- 
retidő) [17] 


1.4.4. . CSMA/CD 


A CSMA/CD (Carrier Sense Multiple Access with Collision De- 
tection — ütközésérzékeléssel kiegészített vivőérzékeléses több- 
szörös hozzáférés) azt jelenti, hogy valamelyik CSMA-t kiegé- 
szítik ütközésérzékeléssel, tehát ha egy állomás nem érzékelt 
vivőt és adni kezdett, utána figyeli a csatornát, és ha egy má- 
sik állomás adását érzékeli, akkor abbahagyja az adást. Ezt 
teljesítményméréssel valósítja meg: ha nagyobb teljesítményt 
érzékel, mint amit ő kiadott, ütközés történt. Ez a módszer azt 
feltételezi, hogy a két legtávolabbi állomás között is csak olyan 
kis csillapítás megengedett, hogy az állomások még érzékeljék 
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egymás teljesítményét." A protokoll továbbfejlesztett változa- 
tát alkalmazzák az Ethernet hálózatoknál, így ezzel részletesen 
fogunk foglalkozni. 


1.4.5. Token Ring 


A Token Ring (vezérjeles gyűrű, IEEE 802.5, 1.15. ábra) már 
elavult hálózatnak számít, így ezzel nem fogunk részletesen fog- 
lalkozni, de a MAC protokollját érdemes egy kicsit megismerni. 
A főbb tulajdonságai: 


. gyűrű topológiát használ (pont-pont közötti kapcsolatok 
fizikailag) 


. a token (vezérjel) egy speciális keret 

e az adhat, akinél a token van 

" többi állomás ismétel (a címzett tárolja is a keretet) 
" a tokent megszabott idő után tovább kell adni 


e ütközés nincs, így jó kihasználtság érhető el 


1.4.6. . Token Bus 


A Token Bus (vezérjeles sín/busz, IEEE 802.4, 1.16. ábra) is a 
múlté, itt is csak a MAC protokolljára vetünk egy pillantást. 
Főbb jellemzői: 


. a topológia: busz/sín 
"Vegyük észre, hogy az egyre kifinomultabb protokollok (ALOHA, ré- 


selt ALOHA, CSMA, CSMA/CD) egyre több feltételt követelnek meg az 
alkalmazhatóságukhoz! 
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1.15. ábra. Token Ring 


72 e 


. az állomások a token továbbítása szempontjából gyűrűt 
alkotnak (logikai gyűrű), azaz mindegyik állomás tudja, 
hogy melyik állomástól kapja és kinek adja tovább a ve- 


zérjelet 
." egy állomás adatkeretet bármely állomásnak küldhet 


A logikai gyűrűbe való belépés versengéses protokollal törté- 
nik, ahol ütközés lehetséges, de az adatforgalom a tokenes MAC 


protokoll miatt itt is ütközésmentes. 


! A l5 





[12 











1.16. ábra. Token Bus 
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FEJEZET 1. BEVEZETÉS 


2. fejezet 


Helyi hálózatok 


A számítógép hálózatokat kiterjedésük alapján általában a kö- 
vetkező kategóriákba szokták sorolni: 


LAN (Local Area Network - helyi hálózat) 
A hálózat átmérője néhány 100 méter (esetleg néhány 
km). Tipikusan egy épület vagy egy telephely számító- 
gépeit kötikössze. Ide soroljuk az Ethernet hálózatok kü- 
lönféle fajtáit és a már elavultnak számító vezérjeles gyűrű 
és vezérjeles busz hálózatokat. Ujabban egyre terjednek a 


WLAN (wireless LAN - vezetéknélküli LAN) megoldások. 


MAN (Metropolitan Area Network - nagyvárosi hálózat) 

A hálózat átmérője néhányszor 10 km. Régebben első 
számú képviselőnek számított az FDDI, és ide tartozott a 
gyakorlatban nem sokat használt DODB is. Ma a MAN 
részének tekintjük a - hozzáférési hálózatként használt - 
ADSL-t, ADSL2-t és VDSL-t is. A kábel TV fölötti adat- 
átviteli megoldások (pl. DOCSIS) sorolhatók még ebbe a 
kategóriába. 
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WAN (Wide Area Network - nagy kiterjedésű hálózat) 
A hálózat átmérője néhány 100 km-től terjedhet a kon- 
tinenseket behálózó hálózatokig. Technológiailag ide tar- 
toznak: X.25, frame relay, bérelt vonal, SDH, ATM, stb. 


A csoportosítás meglehetősen hozzávetőleges. A WLAN 
hálózatokat is szokták hozzáférési hálózatként használni akár 
nagyvárosban" is, de még inkább ritkán lakott területeken, il- 
letve az üvegszálas Ethernet hálózatok bizonyos fajtái is hasz- 
nálhatók ilyen célra! 

Megkülönböztethetjük még a Personal Area Network (sze- 
mélyes térbeli hálózat) kategóriát is, ami tipikusan az Im - 
10 m átmérőjű hálózatokat jelenti, ezeket azonban nem feltét- 
lenül (klasszikus értelemben vett) számítógépek, hanem egyéb 
eszközök, például mobiltelefonok, PDA-k, stb. csatlakoztatá- 
sára használják. A technológiák közül ide sorolható például a 
Bluetooth. Ezzel a kategóriával e jegyzet keretében mélyebben 


nem foglalkozunk. 


2.1. Ethernet hálózatok 


Az Ethernet hálózatokról több könyv is elérhető magyar nyel- 
ven, ezek közül egy áttekintő mű: [6], melynek eredeti angol 
változata is beszerezhető: [7]. Csak a Fast Ethernettel foglal- 
kozik: [13]. 

Az Ethernet hálózatokat eredetileg három együttműködő 
cég, a DEC", az Intel és a Xerox alkotta meg." Ezt 1980-ban 
publikálták az ún. kék könyvben (Blue Book). Azután 1982- 
ben kiadták a második verziót is: Ethernet v2.0, ami néhány 
dologban eltér az eredetitől. 


WMAN-nak kellene nevezni! 

"Digital Eguipment Corporation, ami később beolvadt a Compag-ba, 
ami viszont azután egyesült a HP-vel. 

"Kezdőbetűik alapján ezt a verziót DIX Ethernetnek is hívják. 
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Az IEEE lényegében átvette az Ethernet előírásait, de át- 
fogalmazta, precízebbé tette, valamint bevezetett néhány mó- 
dosítást is, ez lett az IEEE 802.3 szabvány. Mindezek csak 
a (nemsokára ismertetésre kerülő) vastag koaxiális kábel alapú 
technológiát tartalmazták. Azóta sok más közeget is haszná- 
lunk (vékony koaxiális kábel, csavart érpárnak és üvegszálnak 
többféle típusa), ezek az IEEE szabványban kiegészítésként sze- 
repelnek, amit a szabványszámhoz írt kisbetűvel jelölünk, pél- 
dául IEEE 802.3a. A továbbiakban az egyszerűbb szóhasználat 
kedvéért az IEEE 802.3 családba tartozó összes technológiát 
egyszerűen csak Ethernetnek hívjuk. 


2.1.1. — Ethernet hálózatok fajtáinak áttekintése 


Az Ethernet hálózatok fajtáit a következőképpen jelöljük. A 
Base szócskával fejezzük ki, hogy a fizikai rétegben alapsávi kó- 
dolást használunk (és nem valami vivőfrekvenciát modulálunk). 
A Base szócska elé írjuk az átviteli sebességet Mbit/s-ban meg- 
adva. A korábban kifejlesztett koaxiális kábel alapú típusoknál 
a Base után egy számjegy áll, ami (a típus azonosításán túl) 
megadja a szegmenshossz közelítő értékét 100 m-ben kifejezve: 
10Base5 és 10Base2. Az összes többi esetben a Base után álló 
betű, betűkombináció vagy betű és számkombináció csupán azo- 
nosítja a típust, és nem hordoz közvetlenül szegmenshossz in- 
formációt. Például: IOBaseT, 100BaseT4, IDOOBaseSX. 

A 2.1. táblázatban röviden áttekintjük az Ethernet hálóza- 
tok fajtáit." Az első kettő (10Base5 és 10Base2) busz topológiát 
használ, a többi csillagot. A busz topológia előnye, hogy nem 
igényel külön aktív eszközt, hátránya viszont, hogy ha valahol 
megsérül, akkor az egész szegmens üzemképtelen lesz. A csil- 
lag topológia esetében a csillagpontban valamilyen (2.1.7.-ben 
megismerendő) aktív eszköz található. Ebben az esetben egy 





"Van 10 Gbit/s sebességű Ethernet szabvány is, de azt nem tárgyaljuk. 
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zh 


szegmens sérülése miatt csak az adott szegmensen levő állomás 
nem tud kommunikálni. Amint a táblázatban láthattuk, a busz 
topológiájú hálózatok koaxiális kábelt használnak. Ennek nyil- 
ván az az oka, hogy kifejlesztésük idején az akkori technológia 
mellett ez a kábel volt alkalmas a megbízható átvitelre az akkor 
meglehetősen nagynak számító lLOMbit/s sebesség mellett. A 
technológia fejlődése azonban lehetővé tette, hogy árnyékolatlan 
csavart érpárat használjunk ugyanakkora, sőt egyre nagyobb át- 
viteli sebesség mellett. (Az átviteli közegekről bővebben: 2.1.2.) 
Az Ethernet hálózatok egyes fajtáival külön-külön is foglalko- 
zunk 2.1.9-ben, de előbb még meg kell szereznünk a szükséges 
előismereteket. 


2.1.2. Ethernet hálózatok fizikai közegei és csatla- 
kozói 


Vastag koaxiális kábel 


Az Ethernet hálózat legelső fajtája, a 10Base5 50 Ohm-os vastag 
koaxiális kábelf használ átviteli közegként. A busz topológiá- 
ból adódóan a kábel végét a reflexió elkerülése érdekében hul- 
lámimpedanciával (50 Ohm) le kell zárni, ami azt jelenti, hogy a 
kábel végein a kábel belső (ún. meleg) ere és a külső árnyékolás 
közé kell bekötni a megfelelő teljesítményre méretezett 50 Ohm-os 
ellenállásokat, amint a 2.1. ábra is mutatja. 

A vastag koaxiális kábel használatának egyik jelentős hát- 
ránya az, hogy a kábelt (a szerkezetének megóvása érdekében) 
csak kellően nagy sugarú ívben szabad hajlítani, így a szerelése 
nagy gondosságot igényel. 

A kábelen 2,5 méterenként előre kialakított és megjelölt 
csatlakozási pontok találhatók. Ezeken a helyeken a kábel szer- 
kezetét úgy alakították ki, hogy alkalmas legyen a franscei- 


"A kb. hüvelykuüjjnyi vastagságú, sárga színű (egyesek szerint kerti lo- 
csolócsőre emlékeztető) koaxiális kábelt angolul yellow cablenek is nevezik. 
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Típus Átviteli közeg C. Csatla- 
kozó 


MEZCES 500 m 


10Base2 vékony koax (RG 58) ] 185m ]BNC, T- 
(200 m) Í dugó 


I0BaseT UTP (Cat3) 00m TRI 45 
10BaseF 2000m [ $C, ST 
100BaseTX ] UTP (Cat5) 100m ]ÍRJ45 
100BaseT4 ] UTP (Cat3) 100 m 
( 
( 


— 


1Ö0BaseT3 
TO0BaseFX 2000 m 
T000BaseT 100m 
1000BaseSX ! üvegszál 220 1n 5C, ST, 
(MMF 62,5 um) — 
275m 
1000BaseSX [ üvegszál 500 m 
(MME 50/125 um) - 
550m 
1000BaseLX ] üvegszál (MMF) 550m 


1000BaseLX Í üvegszál (SMF, 9 um) 


1000BaseCX [ STP 25m árnyékolt 
RJ 45 


2.1. táblázat. Ethernet hálózat fajták néhány jellemzője [6]. 


7 
a 





verek (magyarul adóvevők)  vámpírcsatlakozóval történő csat- 
lakoztatására. A vámpírcsatoló tüskéje éppen annyira hatol be 
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50£2 50£2 


2.1. ábra. Kábellezárás 


a kábelbe, hogy már biztos kontaktust teremtsen a kábel me- 
leg erével, de ne vágja el azt. A 2.2. ábrán ez kinagyítva is 
látható. A transceiver látja el az adás, a vétel és az ütközés 
érzékelés feladatát. A transceiver az AUI kábelen (Attachment 
Unit Interface cable) keresztül 4 érpár segítségével kommuni- 
kál a számítógépben található hálózati kártyával: adás, vétel, 
vezérlés, tápellátás. (Régi hálókártyákon még megfigyelhető a 
15 érintkezős AUI csatlakozó.) Az Ethernet hálózatok többi 
típusánál a transceiver a hálózati kártyán található! 


A 1l0Base5S5 szabvány szerint egy szegmensre legfeljebb 100 
állomás kapcsolható. 


rose [ANNK 





2.2. ábra. Transceiver vámpírcsatlakozóval 
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Vékony koaxiális kábel 


A tipikusan szürke vagy fekete színű RG 58-as jelzésű vékony 
koaxiális kábel már jóval könnyebben kezelhető, mint a vastag. 
Egyrészt kisebb a hajlítási sugár, másrészt könnyebb a szere- 
lése, mert közönséges ipari BNC csatlakozókat használhatunk. 
10Base2 hálózat építésekor a kábelt minden olyan helyen el kell 
vágni, ahol esetleg számítógép csatlakoztatására lehet szükség. 
A kábelvégekre anya típusú (female) BNC csatlakozó kerül, és 
a kábelvégeket fali csatlakozó dobozban (face plate) rögzítik. 
Ahova nem kötnek be számítógépet, ott a két csatlakozót össze- 
kötik egy mindkét végén apa típusú (male) BNC csatlakozóval 
szerelt rövid koax kábellel (átkötés). Ha egy számítógépet sze- 
retnénk a hálózatba kötni, akkor eltávolítjuk az átkötést, és két 
megfelelő hosszúságú koax kábellel egy T dugót kötünk be a 
hálózatba, a T , függőleges" szárát pedig a számítógépben ta- 
lálható hálózati kártyához csatlakoztatjuk. Több gép esetén a 
gépeket egymás után felfűzzük. Természetesen a hálózati kár- 
tyák villamosan ekkor is egymással párhuzamosan vannak be- 
kötve, és a 10Base5S5-höz hasonlóanitt is 50 Ohm x 50 Ohm — 25 Ohm 
ellenállást látnak egy helyesen lezárt hálózat esetén. A hálózati 
kártyáknak természetesen elvileg végtelen, gyakorlatilag 100 kohm 
nagyságrendű ellenállást kell kifele mutatniuk. 

A 10Base2 szabvány szerint egy szegmensre legfeljebb 30 
állomás kapcsolható. 


Csavart érpáras megoldások 


A jelfeldolgozási technológia fejlődése lehetővé tette a közös mó- 
dusú zavarok hatékony kiszűrését. így a drága és nehezen sze- 
relhető koaxiális kábel helyett ma már csavart érpárat használ- 
hatunk az Ethernet hálózatainkhoz. (Például: IOBaseT, ID0OBa- 
seTX, IDOOBaseT.) Ezek közös jellemzője, hogy egy kábel 8 eret 
tartalmaz, amelyeket páronként összesodortak: így 4 érpárat 
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kaptunk. A sodrás célja, hogy az érpárak mindegyikében (jó 
közelítéssel) azonos zavarjelek indukálódjanak. Az érpárak kö- 
zötti elektromágneses csatolás csökkentése érdekében az egyes 
érpárak sodrási száma" eltérő. Az ennek következtében fellépő 
hosszkülönbségből adódó ellenállás-különbség kompenzálására 
a nagyobb sodrási számú érpárak vastagabbak. 

A csavart érpáras kábelek egyik fontos jellemzője az átvitt 
Jfrekvenciatartomány. Ennek alapján definiálták a következő ká- 
belkategóriákat: 


Cat3 I6MHz-ig 
Cat4 20MHz-ig 
Cat5 100 MHz-ig (eredetileg) 


CatS5e 100 MHZz-ig 1 további követelmények teljesítése: NEXT 
(Near End Cross Talk - közelvégi áthallás), FEXT (Far 
End Cross Talk - távolvégi áthallás). Aztán megszűnt a 
CatSe és a Cat5-nek nevezett tudja azt, amit addig Cat5e- 
nek hívtak. 


Cat6 250 MHz-ig (2002. nyarától szabvány.) 


Cat7 600 MHz-ig (Ajánlások vannak rá, de teljes rendszer nem 
létezik belőle.) 


Egyes gyártók ettől eltérő értékeket is garantálhatnak, pél- 
dául 150 MHz. Azt azonban fontos látnunk, hogy az átvitt 
frekvenciatartomány dimenziója a MHz. Bizonyos gyártók ez- 
zel szemben Mbit/s dimenziójú jellemzőt adnak meg, ami nem 


összemérhető vele! Az elérhető átviteli sebesség természetesen 
az alkalmazott kódolástól is függ, ami NEM a kábel jellemzője! 


méterenként hány sodrás van 
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A gigabites hálózatok az átvitt frekvenciatartományon túl 
a kábellel szemben más fontos követelményeket is támasztanak, 
úgy mint csillapítá, NEXT (Near End Cross Talk - közelvégi 
áthallás) és FEXT (Far End Cross Talk - távolvégi áthallás). 

Mind az áthallás, mind a külső zavarjelek bejutása ellen 
védekezhetünk az egyes érpárak, illetve a kábel árnyékolásá- 
val. Árnyékolásra kábelharisnyát vagy fémfóliát használnak. 
A 2.3. ábra különböző megoldásokat mutat be azok szabványos 
megnevezésével. A ,,/" jel előtti betűk a kábel külső árnyékolá- 
sára, az utána állók pedig az érpárak árnyékolására vonatkoz- 
nak: 


. U: Unshielded — árnyékolatlan 
. S: Shielded — kábelharisnyával árnyékolt 


" F: Foiled — fémfóliával árnyékolt 

Csavart érpáras hálózataink esetén a kábeleket RJ-45 jelű 
csatlakozóval csatlakoztatjuk. Ez a telefonos RJ-11 csatlakozó- 
hoz hasonló, de 8 ér csatlakoztatására alkalmas. Az ereket a 
műanyag borításuk színével azonosítjuk. Az érpárak egyik ere 
a narancs, zöld, kék és barna színek közül valamelyik, a vele 
összecsavart pedig fehér az adott színű csíkkal. Az erek bekö- 
tése így a színsorrenddel adható meg. A 2.2. táblázatban az 
EIA/TIA 568 szabvány szerinti A és B színsorrend látható. 











— 










Erek sorszáma 2 
EIA/TIA568ATZFÍZ]NF 
EIA/TIA 568BÍ NF JNÍZF 

















IK] KF 
IKÍKF] 7 











2.2. táblázat. Csavart érpáras kábel színsorrendje 


A ma legelterjedtebb IDOBaseTX hálózatnál csak két érpá- 
rat használnak: egyet adásra, egyet pedig vételre. A helyes mű- 
ködéshez az egyik állomás adóját a másik állomás vevőjére kell 
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U/UTP 






F/UTP SF/UTP 





S/FTP (Cat. 7) 


2.3. ábra. Csavart érpáras kábelek [38] 


kötni és viszont. Ha két állomást közvetlenül szeretnénk egy- 
mással összekötni, akkor tehát keresztkábelt (cross-over cable) 
kell használnunk, amelynek az egyik végének a bekötése az 4, 
a másik végének bekötése pedig a B sorrendet követi. Az aktív 
eszközök csatlakozójánál már elvégezték a cserét, ezért aktív 
eszköz és számítógép közé egyenes kábelre van szükség. (Ez le- 
het akár A-A, akár B-B bekötésű, az utóbbit szoktuk használni.) 
Két aktív eszköz összekötésére természetesen keresztkábelt kell 
használni. 
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A strukturált kábelezéssel a 2.2. alfejezetben külön foglal- 
kozunk, mivel a strukturált kábelezés az Ethernet hálózatokon 
kívül másra is használható. 


Üvegszálas megoldások 


Az üvegszál a teljes visszaverődés fizikai jelensége miatt alkal- 
mas átviteli közegnek. Alapvetően két fajtája van: a többszörös 
módusú üvegszál (MMF - Multi Mode Fibre), aminek a mag- 
átmérője viszonylag nagyobb (50 um vagy 62,5/ um) , és az egy- 
szeres módusú üvegszál (SMF - Single Mode Fibre), aminek a 
magátmérője kisebb (9/um). 

A többszörös módusú üvegszálban a fény több úton is terjed- 
het. Természetesen az eltérő úthosszak megtételéhez szükséges 
idő is eltérő, így a jel diszperziót szenved, aminek az a következ- 
ménye, hogy az áthidalható távolság kisebb, mint az egyszeres 
módusúnál. 

A magátmérők ismeretében érthető, hogy az üvegszálak csat- 
lakoztatása kellően nagy pontosságot igényel. Az egyik legelter- 
jedtebb csatlakozó az SC, ami közelítőleg négyzet keresztmet- 
szetű és csatlakoztatáskor bekattanva rögzítődik, így nem eshet 
ki, csak viszonylag nagyobb erővel lehet kihúzni. Van amikor a 
két irány (adás és vétel) üvegszálának csatlakozója egyben van, 
így egy darab téglalap keresztmetszetű dugóval találkozunk. A 
másik elterjedt csatlakozó az ST, ami a BNC-hez hasonló, de 
vékonyabb. Ezt főleg a patch paneleken használják. Egy har- 
madik megoldás, amivel például 3Com eszközöknél találkozha- 
tunk, az MTRJ. Ez jóval kisebb méretű, és a két szálat együtte- 
sen csatlakoztatja (duplex). Újabban egyre jobban terjed az LC 
csatlakozó. Ez kinézetre az SC-hez hasonlít, de lényegesen ki- 
sebb annál, aminek előnye, hogy körülbelül akkora helyet foglal 
el mint egy RJ 45, így portsűrűségben jó. Általában duplex. 

A lefektetett optikai kábelek több (4-8-12, stb.) optikai szá- 
lat tartalmaznak, és megfelelő mechanikai védelemmel vannak 
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ellátva. 


2.1.3. — Vonali kódolási megoldások 


Digitális információ átvitelére sokféle kódolás alkalmazható. Is- 


merjünk meg néhányat a 2.4. ábra alapján! 
I[[10 
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2.4. ábra. Kódolási eljárások 


NRZ (Non Return to Zero) kódolás esetén egy bit 0 értéké- 
nél a jel a teljes bitidő alatt —/V feszültségszintet vesz 
fel, 1 értékénél pedig 4/V értéket. Gondot jelenthet, ha 
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hosszú egyes (vagy nullás) sorozat van, mert pozitív (vagy 
negatív) egyenáramú komponens jelenik meg, valamint a 
szintváltás hiánya miatt szinkronvesztés következhet be. 


NRZI (Non Return to Zero Inverted) kódolásnál I-es bit ese- 
tén a bitidő közepén invertálni kell a feszültségszintet, 0 
esetén nincs váltás. Hosszú 0 sorozat esetén itt is bekö- 
vetkezhet a szinkronvesztés. 


Manchester kódolás esetén a bitidő közepén 0 értékű bitnél 
lefelé kell vinni a feszültségszintet, míg 1I-nél felfelé. Ha 
azonos értékű bitek érkeznek egymás után, a bitidő hatá- 
rán váltani kell, különben nem. A megoldás előnye, hogy 
mivel a bitidő közepén mindig van szintváltás, ezért nem 
következhet be szinkronvesztés. Ennek az ára viszont a 
megnövekedett sávszélesség igény! 


Differenciális Manchester kódolást használva 0-nál a bitidő 
elején és közepén is van váltás, míg I-nél csak a közepén. 
Szintén véd a szinkronvesztés ellen, szintén a sávszélesség 
rovására. 


MLT-3 kódolás esetén a jelnek 3 feszültségszintje lehet: po- 
zitív, negatív, és 0. A váltások a következő sorrendben 
történnek: 0 -5 AV 6-5 0 -3 -V -3 0-5... stb. Az 1- 
esnél a bitidő elején váltás történik a megadott sorrend 
szerint, 0-nál pedig nincs váltás. Hosszú 0 sorozat ese- 
tén itt is bekövetkezhet szinkronvesztés. A sávszélesség 
felhasználása kedvező. 


FM-0O kódolásnál a jelszint a bitidő elején és végén mindig az 
ellenkezőjére vált, 0-nál a közepén is vált, 1-esnél középen 
nem vált. Az órajelet megtartja. 


A vevő nem tudja az adó órajelét követni. 
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A fentiekből úgy tűnhet, mintha a szinkronvesztés kiküszö- 
bölése és a sávszélesség hatékony felhasználása egymást kizáró 
követelmények lennének. Ez nincs így, csak fejlettebb kódolási 
eljárásokra van szükség. Nézzünk meg néhányat ezek közül is! 


4b/5b kódolás esetén a bemenet minden 4 bitjét egy-egy al- 
kalmas 5 bites szimbólummal helyettesítjük. Mivel így a 
2 - 16 helyett 27 — 32 szimbólum áll rendelkezésünkre 
(2.5. ábra), megoldható, hogy csak olyan szimbólumokat 
használjunk, melyeknek az elején legfeljebb egy, a végén 
legfeljebb két nulla értékű bit áll. Ezzel a választással el- 
értük, hogy egymás után maximum három nulla értékű 
bit helyezkedhessen el. így megakadályoztuk a hosszú 0 
sorozat kialakulását, ami azért fontos, mert a 4b/5b kó- 
dolás után általában az NRZI kódolást használjuk, ahol a 
hosszú 0 sorozat szinkronvesztést okozhatna. 


A 16 db adatszimbólum mellett van 8 speciális szimbólum, 
ami például keret eleje/vége, vonalállapot, logikai értékek, 
stb. jelzésére használható. A további 8 szimbólum érvény- 
telen. 


$b/10b kódolásnál a 2" — 1024 lehetséges kódszimbólumból 
2" — 256 db-ot használunk az adatok kódolására. 


8b/6t kódolásnál minden 8 bitet 6 db három szintű (terciális) 
szimbólummal kódolunk. 


PAM-5 kódolásnál 5 szintet használunk: -2, -1, 0, 1, 2. Te- 
hát: ha már nem lehet a kábelen a frekvenciatartományt 
növelni, a feszültségszintek számát még igen! 
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Vonal állapot jelző Adat szimbólumok 


TITI ún 0 0000 

ig all: sat S allák : SBi.: —-TTL 001001 l 0001 
TU crjaoln ü dézú TIT L.. 10100 2 0010 
sF  — Ü01090 H Halt TÁ.T főt a GYE 
Keret kezdet jelző I LL 0 BIBi0 4 0100 

ad LT Bigii 5 0101 

TL— 11000 0 J JÁT OttIG 6 bitó 
1 L 10001 K zFITL OXI 7 $iji 
Keret vég jelző T LL. ÍHRI0 8 1000 


J tá 10011 9 1001 
01101 T Terminator § up B. ii 10110 A 1010 


Vezérlési állapot jelzők T UL 1011 0 B 0 I01I 


(Logikai 0/1 megfelelői) JE.I  — Jí0í0 É 1100 

—  fiFT úöjii R ls Tee ÍXÜi D 1101 
AT 11001 s Set J1LI "—" ItII00 E 1110 
a ET áz TEL699 F titi 


2.5. ábra. 4b/5b 4 NRZI kódolás érvényes szimbólumai [6] 


2.1.4. — Ethernet hálózatok MAC protokollja 


A 10Base5 és a 10Base2 hálózatok MAC protokollja az 1-per- 
zisztens CSMA/CD kettes exponenciális visszatartással kiegé- 
szítve. A csavart érpáras hálózatok közül half duplex" üzem- 
módban ezt használja például a IOBaseT és a IOOBaseTX. 
Hogyan működik ez a protokoll? Ha egy állomásnak van 
adni valója, belehallgat a csatornába. Ha adást érzékel, akkor 
megvárja, amíg az abbamarad, közben folytonosan figyeli a csa- 
tornát. Amikor szabad(dá vált) a csatorna, azonnal adni kezd. 
Ha a keret adása során nem érzékel ütközést, akkor a feladatát 
befejezte. Ha ütközést érzékel (teljesítményméréssel), akkor egy 
rövid ideig (32 bit ideje) zavarjelet (álvéletlen bitsorozatot) ad, 


Olyan kétirányú átvitel, amikor az egyik és a másik irányban csak 
egymás után váltakozva történhet az adattovábbítás. 
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hogy a többi állomás is érzékelje az ütközést. Ezután az adá- 
sát abbahagyja. Ez most az első ütközése volt, amiben részt 
vett. Tegyük fel, hogy már az n-edik sikertelen kísérletnél tart. 
Ekkor a 2"T hosszú (ahol T egy adott érték) intervallumból vé- 
letlenszerűen választott időt vár, mielőtt újra próbálkozna. Az 
intervallum hossza legfeljebb 2"T-ig nő, a későbbi próbálkozá- 
soknál változatlan, és összesen legfeljebb 16-szor próbálkozik. 
Mivel az intervallum hossza exponenciálisan nő, ezért még ha 
nagy számú állomás vett is részt az ütközésben, akkor is kellően 
hamar megtörténik az ütközés feloldása. (Valamelyik állomás- 
nak sikerül a többit megelőznie, és amikor a többiek érzékelik 
az adását, akkor már természetesen nem vágnak a szavába.) 

Ahhoz, hogy ez az algoritmus használható legyen, feltétle- 
nül szükséges, hogy még a keret adása alatt minden résztvevő 
állomás felismerje az ütközést! Nézzük meg, mi történne, ha 
a 2.6. ábrán látható szituáció állna elő! Az ábrán a függőleges 
tengely mentén helyezkednek el az állomások, a vízszintes ten- 
gely pedig az időt ábrázolja. Az ,A" és a ,C" állomás adása 
szemmel láthatóan átlapolódik, de az ütközést egyikük sem ér- 
zékeli, mert mire a másik állomás kerete odaér hozzájuk, arra 
már befejezték a saját keretük leadását. Annak érdekében, hogy 
ezt a szituációt elkerüljük, a keret hosszának! el kell érnie egy 
bizonyos értéket. Helyesen megválasztott kerethossz esetén a 
probléma nem áll elő: 2.7. ábra. A legkisebb megengedett ke- 
rethossz 64 byte. 


2.1.5. — Ethernet keret felépítése 


Topológiától és adatsebességtől függetlenül az Ethernet háló- 
zatok összes fajtája a 2.8. ábrán látható keretszerkezetet hasz- 
nálja. Az első két mező tulajdonképpen a fizikai réteghez tar- 

Valójában adási időtartamának, de ez a 10Base5 és 10Base2 hálóza- 


toknál még ugyanazt jelentette. 
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Kábelen való 
pozíció 
A — keretkezdet — keretvég 
s ———— 


B 


c —k 


D 


2.6. ábra. Ütközés túl rövid keretidő esetén 


Kábelen való 


OZÍCiÓ 
P ! " keretkezdet keretvég 
B 
c —— —Ó——— ——Ú-$OÚőŰ/f/[.ÉÚŐÜŰÍl 
D 


f 


2.7. ábra. Ütközés helyesen megválasztott keretidő esetén 


tozik, de ezeket is bele szoktuk érteni a keretbe. 
Az IEEE 802.3 keret az alábbi mezőket tartalmazza: 


PREAMBLE előtag, (bájtonként: 10101010) 
Ez a bitsorozat arra szolgál, hogy a vevő az óráját az adó 
órájához szinkronizálhassa. (Például 10 Mbit/s sebességű 
hálózatnál 1 bit ideje: 100ns, a 7bájt 56 bitjének ideje 
tehát 5,6 us.) 
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a fizikai réteghez tartozik MAC szintű keret 


2.8. ábra. Az IEEE 802.3 keretszerkezete 


START OF FRAME keretkezdet határoló (10101011) 


Az előtaghoz képest az utolsó bit I-es értéke jelzi, hogy 
utána már a célállomás címe következik. 


DESTINATION ADDRESS célcím 


Bár az IEEE 802.3 megengedi a 2 bájtos hosszt is, gyakor- 
latilag mindig 6 bájt hosszú. Célszerű volt a többi mező 
elé tenni, hogy minden állomás minél előbb felismerhesse, 
hogy kinek szól a keret. 


SOURCE ADDRESS forráscím 


LENGTH adatmező hossza (IEEE 802.3) 


A DIX Ethernet és annak v2.0 változata ezt a mezőt 
EtherType-nak nevezi, ami azt adja meg, hogy az adatme- 
zőben milyen protokoll adategysége utazik. (A két meg- 
oldás akár egy hálózaton belül is használható, ugyanis az 
aktuális értékéből felismerhető, hogy hogyan kell értel- 


mt 


mezni! Ha a mező értéke 0-1500 bájt közötti, akkor hossz, 


b. 


ha ettől eltérő, akkor EtherType.) 


DATA adatok 


Itt található beágyazva a felsőbb rétegbeli protokoll adat- 
egysége. 
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PADDING kitöltés 
A keret minimális hossza 64 bájt, ha nincs annyi, ki kell 
egészíteni. 


CHEKCSUM ellenőrző összeg 
Ha megegyezik a számított és a vett érték, akkor a keretet 
hibátlannak tekintjük, ellenkező esetben a keret sérült. 


Az összes Ethernet hálózati kártya egyedi címmel rendelke- 
zik. Ezt úgy valósítják meg, hogy a cím 6 bájtját két részre bon- 
tották. Az első 3 bájtot az IEEE osztja ki a gyártók részére." 
A másik 3 bájtot pedig a gyártók osztják ki az általuk gyártott 
eszközöknek. Bár az OUI (Organizationally Unigue Identifier) 
elvileg 24 bites, gyakorlatilag csak 22 bitet használnak a gyár- 
tók azonosítására, ugyanis az első két bit más célt szolgál: az 
[/G bit (individual / group) 0 értéke azt jelenti, hogy valóban 
egy kártya egyedi címéről van szó, az 1 értéke esetén a cím egy 
csoportcím (multicast address). Ha az U/L (universal / local) 
bit értéke 0, akkor valóban univerzálisan (helyesebben: globá- 
lisan) adminisztrált címről van szó, aminek az egyedisége az 
imént említett módon biztosított, ha pedig a bit értéke 1, akkor 
a címet a rendszergazda osztotta ki (erre bizonyos protokollok 
esetén szükség lehet). 

Itt említjük meg még a broadcast címet, ami 48 darab I-es 
bitből áll. Az ilyen címre küldött kereteket minden hálózati 
kártya veszi. 


2.1.6. — Ethernet keretek hibái 


Ethernet hálózatokban akár üzemszerű/helyes működés közben, 
akár meghibásodás miatt keletkezhetnek hibás keretek. Ezeket 
a következő (nem diszjunkt) csoportokba soroljuk: 


VA kiosztott azonosítók listája megtalálható: [25] 
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Runt A kerethossz kisebb, mint 64 bájt. Leggyakoribb oka az, 
hogy ütközés miatt az állomások abbahagyják az adást. 
Ez a fajta hibás keret tehát egy hibátlanul működő háló- 
zatban is előfordulhat. 


Jabber , fecsegés" A kerethossz nagyobb 1518 bájtnál (a má- 
sodik rétegben mérve)." 


Keletkezésének lehetséges okai: 


e az állomások nem veszik észre az ütközést 


. adó (hálózati kártya) meghibásodása 
Ez tehát minden esetben hálózati hibát jelent. 


Misaligned frame , rosszul elrendezett/igazított" keret. A ke- 
ret bitjeinek száma nem osztható 8-cal. Ha például runt- 
tal együtt fordul elő, akkor nem jelent hálózati hibát. 


Bad FCS A számított ellenőrző összeg nem egyezik a vett ke- 
ret utolsó 32 bitjével. Oka lehet bithiba vagy csonkolódás. 
Ütközés miatt előfordulhat jól működő hálózatban is, de 
utalhat hibára is. (Például UTP kábelnél elcserélt ér mi- 
atti áthallás full duplex" módban a két irány között.) 


Természetesen egy misaligned frame esetén az ellenőrző ösz- 
szeg is hibás. Runt és Jabber esetén valószínű a misaligned 
frame és szinte biztos a bad FCS. 


2.1.7. Ethernet hálózatok aktív elemei 


A 10Base5 és 10Base2 hálózatok busz topológiájúak, és a mű- 
ködésükhöz elegendő, ha a buszt mindkét végén hullámimpe- 
danciával lezárjuk, valamint természetesen állomásokat kötünk 


"Azaz 1526 bájtnál az első rétegben mérve. 
"azonos időben történő átvitel mindkét irányban 
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rá. Mivel a szegmenshossz korlátos, felmerül az igény több szeg- 
mens összekapcsolására. Az összekapcsolás többféle eszközzel is 
történhet, attól függően, hogy mi a célunk. 

A legegyszerűbb esetben, ha csak a szegmenshossz által oko- 
zott korlátokat szeretnénk tágítani, elegendő a szegmenseket 
első rétegbeli funkcionalitással összekapcsolnunk. Ezt valósítja 
meg a repeater (2.9. ábra). 


] ff ] 
iaT LBJ [c] 


Repeater ) 
enné ! 1 
FELÍBM L szen 
ID] (El [FI] 





2.9. ábra. Hálózati szegmensek összekapcsolása repeaterrel 


A repeater olyan hálózati eszköz, amely az egyik portján 
vett adatokat a többi portján (jelregenerálás után) kiadja. A 
szegmensekből egy ütközési tartományt (collision domain) ala- 
kít ki, ha tehát a szegmenseken lévő bármelyik két állomás egy- 
szerre kezdeményez adást, ütközhetnek. (Az első rétegben mű- 
ködő eszköz.) 

10Base5 hálózat esetén a szegmensek összekapcsolására az 
alábbi szabályt? kell alkalmazni az összes jelútra vonatkoz- 
tatva. 


e maximum 5 szegmenst tartalmazhat 


e maximum 4 repeatert tartalmazhat 


BÜgy is hívják, hogy: 5-4-3 szabály. 
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. maximum 3 szegmensen lehetnek állomások (a többi csak 
inter-repeater link lehet) 


Természetesen a repeaterek alkalmazása nem mindig felel 
meg a céljainknak. Az így összekapcsolt szegmenseken levő ál- 
lomások ugyanazon a sávszélességen osztoznak, nem lehetséges, 
hogy például a 2.9. ábrán látható hálózat esetében az , A" ál- 
lomás a , B"-nek, a , D" pedig az , FH-nek egyidejűleg küldjön 
keretet, hiszen a repeater miatt ezek ütköznek. Ehhez 2. réteg- 
beli összekapcsolást végző eszközre van szükség, amit bridgenek 
nevezünk. 


A bridge olyan hálózati eszköz, amely miután megtanulta, 
hogy melyik portján milyen MAC című állomások vannak, egy 
keretet csak akkor továbbít (azon a portján keresztül, ahol a 
címzett található), ha az nem azon a porton érkezett, amelyiken 
a címzett van. A keretek továbbításakor szabályosan lejátssza a 
MAC protokollt, hiszen a 2. rétegben működik. A bridge tehát a 
hozzá kapcsolódó szegmensekből külön ütközési tartományokat 
képez. így a 2.10. ábrán található hálózat esetén már képes az 
,A" állomás a ,, B"-nek, a , D" pedig az , F"-nek egyidejűleg keretet 
küldeni. Általános esetben egy bridge-nek kettőnél több portja 
is lehet, ilyenkor természetesen csak arra a portra továbbítja a 
keretet, ahol a címzett van." 

Ennél magasabb szintű, 3. rétegbeli összekapcsolással majd 
a 3. fejezetben foglalkozunk. 

A csillag topológiájú hálózatokban pedig eleve szükség van 
egy aktív eszközre, ami összekapcsolja az állomásokat. Ezt meg- 
tehetjük akár az 1. rétegben a hub vagy a 2. rétegben a switch 
segítségével. 

A hub a többportos repeater újabb neve a csillag topológi- 
ájú hálózatokban. 

A switch pedig egy többportos bridge, ami külön ütközési 


"Amíg nem tudja, hogy hol van, addig minden portra továbbítja. 
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2.10. ábra. Hálózati szegmensek összekapcsolása bridge segítsé- 
gével 


tartományokat képez. Alapvetően két módban működhet: 


e. store and forward - végigveszi a keretet és tárolja, majd 
a MAC protokoll szabályai szerint továbbítja 


. cut through - elkezdi venni a keretet, majd kis késleltetés- 
sel (a célcím megállapítása után) a MAC protokoll szabá- 
lyai szerint továbbítja 


Lehetóség van egy harmadik, adaptív módra is, ami azt je- 
lenti, hogy a fenti két mód közül a forgalomnak megfelelőt hasz- 
nálják: kis forgalom esetén a cut through üzemmódot használ- 
ják, majd ha az ütközések másodpercenkénti száma meghalad 
egy korlátot, átváltanak store and forward üzemmódba. Ha 
az ütközések száma lecsökken, akkor természetesen ismét cut 
through üzemmódba váltanak. 

Megjegyezzük, hogy (amint fent említettük) a swicth port- 
jai külön collision domaint alkotnak, de egy broadcast domaint 
képeznek, broadcast címre küldött kereteket a switch az 
Összes portjára továbbítja. 

Összefoglalásul azt mondhatjuk, hogy a szegmensek össze- 
kapcsolása történhet fizikai szinten (ekkor az összes állomás 
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egy ütközési tartományt alkot, 2.11. ábra) és adatkapcsolati 
szinten (ekkor a szegmensek külön ütközési tartományt képez- 
nek, 2.12. ábra). A csillag topológiájú hálózatoknál minden- 
képpen szükséges valamilyen aktív eszköz, ezeket másképp ne- 
vezik, mint a busz topológiájú hálózatoknál. Az elnevezéseket 
a 2.3. táblázatban foglaltuk össze. 


busz topológia í csillag topológia 


adatkapcsolati szintén 


2.3. táblázat.  Hálózatrészek összekapcsolására szolgáló aktív 
eszközök megnevezése 
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2.11. ábra. Hálózatrészek összekapcsolása fizikai szinten 


2.1.8. — Ethernet hálózatok fejlődése 


Azt már említettük, hogy az Ethernet fajtái között a 10Base5 
volt az első, majd a l0Base2 követte. A IOBaseT sem volt 
gyorsabb, a jelentősége az, hogy bevezették a csavart érpáras 
kábelek használatát. 
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2.12. ábra. Hálózatrészek összekapcsolása adatkapcsolati szin- 
ten 


Az igazi előrelépést a Fast Ethernet jelentette, ami meg- 
tízszerezte a sebességet. Ehhez a /OOBaseX technológiát az 
FDDI-tól" (Fibre Distributed Data Interface) vették át. A 
100 Mbit/s-os Ethernet hálózatok fejlődését a 2.13. ábrán kö- 
vethetjük. A IOOBaseX technológia a csavart érpárból már a 
Cat5 minőséget igényli, és ezen full duplex működésre képes: ez 
a 100BaseT7X, míg üvegen 1008BaseFX-nek hívják. 

E jegyzet írásának idején" a használatban levő és a telepí- 
tésre kerülő Ethernet hálózatok döntő többsége Magyarorszá- 
gon a IDOBaseTX (Cat5/Cat5e kábelezéssel). Máshol" azon- 
ban már egy-két évtizeddel korábban nagy összegeket ruház- 
tak be a Cat3 (esetleg Cat4) kábelezésbe. Annak érdekében, 
hogy ez a beruházás ne vesszen el, kifejlesztettek ilyen köze- 
geken működő IO0OMbit/s sebességű Ethernet hálózatokat is. 
Előbb a /00BaseT4-et, amely mind a négy érpárat használja", 
ezért egyszerre csak egy irányban tud forgalmazni (half duplex), 


SAz érdeklődőknek ajánlunk az FDDI-ról egy kiváló könyvet: [11]. 
1 2006. 
" például: USA 
5 Egészen pontosan két érpár kétirányú a másik két érpár pedig egyik, 
illetve másik irányra van fenntartva, így irányonként három érpárat hasz- 
nál. 
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(full—duplex capable) 
SI00BaseT2 TERE 802.3y 27 


ős e 
100BaseT IEEE 802.3u 
i I8SESH8 100BaseTX 
Generic 
standard 
1009BaseX (full-duplex capable) 
FDDI 
physical 
ii 100BaseFX 


2.13. ábra. A I00Mbit/s-os Ethernet hálózatok fejlődése [6]. 


majd a 100BaseT2-t, amely egy érpáron éri el ezt a sebességet, 
így full duplex működésre képes. Nálunk azonban ezek a rend- 
szerek egyáltalán meg sem jelentek, nem volt miért! 


A gigabites Ethernet hálózatok fejlődése két irányból merí- 
tett. Egyrészt a 100BaseT2 technológiára építve kifejlesztették 
a Cat5 kábelen működő 1000Base1T hálózatot, másrészt a Fibre 
Channel technológia fizikai rétegét átvéve megalkották az üveg- 
szálat használó I000BaseSX és I000BaseLX valamint az STP 
kábelen működő 1000BaseCX hálózatokat: 2.14. ábra. 


A 2.15. ábrán követhetjük a gigabites technológia logikai fel- 
építését. A MAC réteg (ami azonos az alacsonyabb sebességű 
Ethernet hálózatokéval) vezérli a közegfüggetlen gigabites in- 
terfészt (GMII - Gigabit Medium Independent Interface). Ha 
ez alatt a Fibre Channelből átvett megoldás van, akkor előbb 
egy 8b/10b kódolás történik, majd a megfelelő optikai (1000Ba- 
seLX, 1000BaseSX) vagy réz alapú (1000BaseCX) interfész kö- 
vetkezik. Egyébként pedig az 1000BaseT megoldás megfelelő 
rétegei találhatók. 
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2.14. ábra. Az 1 Gbit/s sebességű hálózatok fejlődése [6]. 
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2.15. ábra. Gigabites technológia architektúrája [40] 


Gigabites hálózatokat jelenleg még főként gerinchálózati" 


" Hálózatok felépítésével a 2.2. alfejezetben foglalkozunk, ott tisztázzuk 
majd a gerinchálózat jelentését. 
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célra használnak, de már terjedőben vannak a gigabites munka- 
állomások is." 

Léteznek már 10 Gbit/s sebességű Ethernet hálózatok is. 
Ezekkel nem foglalkozunk. 

Végül fontosnak tartjuk megemlíteni, hogy a csavart érpá- 
ras technológiák eszközei általában (de nem mindig) visszafele 
kompatibilisek abban az értelemben, hogy egy nagyobb sebes- 
ségű eszköz képes alacsonyabb sebességen is működni. A mű- 
ködési módban a hálózati eszközök automatikusan megállapod- 
nak (auto negotíation). A következő sorozatból a lehető legjobb 
olyat választják, amit mindkét eszköz és a kábelezés is lehetővé 
tesz: IDOOBaseT full duplex, IDOOBaseT half duplex, 100Ba- 
seTX full duplex, 100BaseT2 full duplex, IDOBaseTX half dup- 
lex, 100BaseT2 half duplex, 100BaseT4, IOBaseT full duplex, 
lIOBaseT half duplex. 


2.1.9. . Ethernet hálózatok egyes fajtáinak össze- 
foglalása és értékelése 


Összefoglaljuk az Ethernet hálózatok egyes fajtáinak legfonto- 
sabb jellemzőit. Természetesen az egyes fajtákkal jelentőségük- 
nek megfelelően foglalkozunk. A 27. oldalon található 2.1. táb- 
lázat adatait nem ismételjük meg. (A hivatkozásra kerülő kó- 
dolások leírása a 34. oldaltól található meg.) 


10Base5 és 10Base2 


Vastag és vékony koaxiális kábelen működő, busz topológiájú 
hálózatok. A fizikai rétegben Manchester kódolást használnak. 
Csupán történeti jelentőségük miatt és didaktikai célból (a ké- 
sőbbiek megértése érdekében) érdekesek, egyébként a gyakor- 

9 Jobb minőségű PC alaplapokon az integrált hálózati illesztő már általá- 


ban IOBaseT/I10OBaseTX/IO0OOBaseT, de általában ezek csak I0OBaseTX- 
ként működnek, mivel ilyenek a telepített hálózati aktív eszközök. 
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latban a hallgatóink főleg úgy kerülhetnek kapcsolatba velük, 
hogy le kell bontaniuk őket. :-) 


lOBaseT 


Legalább Cat3 csavart érpáras kábelen működő csillag topoló- 
giájú hálózat. A gyakorlatban főleg úgy találkozunk ilyen esz- 
közökkel, hogy a Cat5 kábelezésű hálózatainkon található még 
néhány ilyen eszköz is. Mivel a IDOBaseTX aktív eszközei általá- 
ban mind 10 mind 100Mbit/s működésre képesek (dual speed), 
ezért legtöbbször nem okoznak problémát. Gondot akkor okoz- 
hat, ha valamely aktív eszköz csak I00Mbit/s működésre ké- 


pes.? 


IOOBaseTX 


Legalább Cat5 minőségű csavart érpáras kábelen működő csillag 
topológiájú hálózat. A fizikai rétegben először 4b/5b kódolást 
használ, az eredményt pedig NRZI kódolással adja ki a vonalra. 
Működhet half duplex üzemmódban hub használatával is, de 
ma már általában full duplex üzemmódban switch használatá- 
val működtetjük a hálózatainkat. Hallgatóink a tárgy gyakorla- 
tain alaposan megismerhetik, mert jelenleg ez a legelterjedtebb 
hálózat. Figyeljük meg, hogy a 4b/5b és NRZI kódolás miatt a 
jelzési sebesség I25Mbaud! 


Természetesen a probléma nem megoldhatatlan: PC esetén ilyenkor 
általában olcsón IOOBaseTX-re cserélhetjük a IOBaseT hálózati illesztő- 
kártyát. Vannak olyan eszközök, műszerek, ahol ez nem tehető meg, ekkor 
pedig keresnünk kell egy dual speed aktív eszközt, amit egyrészt összekö- 
tünk az üzemszerűen használt, csak 100 Mbit/s-os működésre képes aktív 
eszközünkkel, másrészt rákötjük a 10 Mbit/s-os eszközöket. 
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I0OBaseFX 


A IOOBaseTX üvegszálas párja. Jelentóségét főleg a nagyobb 
áthidalható távolság adja. Használatát ezenkívül villámvédelmi, 
speciális körülmények között érintésvédelmi szempontok indo- 
kolhatják. Új gerinchálózat építése esetén valószínűleg inkább 
gigabites optikai kapcsolatot építünk. 


100BaseT4 


$b6t kódolást használ, majd a kódolt információt az irányon- 
kénti 3 fizikai csatornán meglehetősen bonyolult módon viszi 
át. így I0OMbit/s sebességű half duplex átvitelt tesz lehetővé 
legalább Cat3 minőségű sodrott érpáras hálózaton. 
Magyarországon nincs gyakorlati jelentősége. 


100BaseT2 


Ötszintű impulzus-amplitúdó moduláció (PAM-5) használatával 
100Mbit/s sebességű full duplex átvitelt tesz lehetővé legalább 
Cat3 minőségű sodrott érpáras hálózaton. 

Magyarországon nincs gyakorlati jelentősége. 


IO00OBaseT 


A 100BaseT2-höz hasonlóan az 1000BaseT is PAM-5 kódolást 
alkalmaz, viszont a I00BaseTX-hez hasonlóan Cat5/Cat5e ká- 
belen 125 Mbaud jelzési sebességgel működik, de a 4 érpár mind- 
egyikét egyidejűleg használva. 

A rendszer azért képes mégis full duplex működésre, mert a 
szuperpozíció elvét kihasználva az állomások a vett jelből kivon- 
ják a saját maguk adását, és így megkapják, hogy mit küldött 
a másik állomás, lásd 2.16. ábra. 

Az 1000BaseT megoldás jelentősége azért igen nagy, mert 
az elterjedten használt Cat5/CatS5e kábelezésen képes gigabi- 
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250 Mb/s 





2.16. ábra. Full duplex átvitel megoldása [40] 


tes sebességet nyújtani. így kiválóan alkalmas akár gerincháló- 
zatnak, akár szerverek csatlakoztatására, akár - igény esetén - 
egyedi munkaállomások számára nagy sebességű hálózati kap- 
csolatnak. 


I00OBaseSX 


A Fibre Channel technológiát vette át. Többszörös módusú 
üvegszálon, rövid hullámhosszon (850 nm) működik. A fizikai 
rétegben 8b/1l0b kódolást használ. 


Kiválóan alkalmas gerinchálózati célokra. (Az ára miatt asz- 
tali gépekhez nem használjuk.) 
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IOOOBaseLX 


Az I00OBaseSX-hez képest annyi a különbség, hogy a hullám- 
hossza 1300 nm és egyszeres módusú üvegszálon az áthidalható 
távolság lényegesen nagyobb. (Lásd a pontos adatokat a 27. ol- 
dalon található 2.1. táblázatban.) 


IOOOBaseCX 


Bár a Fibre Channelból ezt is átvették és a szabványnak ré- 
sze, a gyakorlatban az IOOOBaseT-vel szemben meglehetősen 
esélytelen a negyedakkora áthidalható távolság miatt, ráadásul 
árnyékolt technológiát követel. 


2.2.  Strukturált kábelezés - a passzív há- 
lózat" 


Ez nem egy másik hálózattípus, hanem csupán egy kábelezési 
szabvány, azért tárgyaljuk külön alfejezetben és nem az Ether- 
nettel együtt, mert másra is használható. Éppen az a lényege, 
hogy egy végpontról nem kell előre eldöntenünk, hogy mire hasz- 
náljuk. Nem készítünk külön telefonhálózatot és számítógép- 
hálózatot, hanem csak egyetlen strukturált hálózatot. Ugyanaz 
a csavart érpár mindkét célra alkalmas lehet, csak a bekötéskor 
kell döntenünk, és igény szerint később a célját meg is változ- 
tathatjuk. 


A strukturált kábelezési rendszer passzív részei: 


. Főrendező (számítógép-hálózati, illetve telefonos rendező 
együtt) 


"Kárpáti László, a PrimusNet Kft. munkatársa elóaadásanyagának [38] 
felhasználásával készült. 
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. Gerinckábelezés (vertikális kábelezés, újabban optikai kö- 
zegen) 


. Alrendezők (vízszintes kábelezés elosztóközpontjai) 
. Vízszintes kábelezés (rézalapú sodrott érpáras kábelezés) 
." Fali csatlakozók, padló dobozok 


Egy strukturált kábelezéssel készített számítógép- és tele- 
fonhálózat látható a 2.17 ábrán. 

A rendezőszekrényekben patch paneleken végződtetik a ká- 
beleket. A rendszer részeit hierarchikus rendszerben számozzák, 
így például az , R1 2/15" az 1. sz. rendezőszekrény 2. sz. patch 
panelének 15. sz. végpontját jelenti. Itt találhatók az aktív esz- 
közök is, amelyekbe patch kábelek segítségével kötik be a kívánt 
végpontokat. Ugyancsak patch kábel segítségével kötik be a fali 
csatlakozóra (vagy padlódobozba) a számítógépeket: 2.18 ábra. 

Fontos, hogy a strukturált kábelezésnél minden csatlakozó 
RJ-45-ös, így ha analóg távbeszélő készüléket szeretnénk be- 
kötni, akkor a telefonzsinór egyik végére is ilyen csatlakozót 
kell szerelnünk, mert az RJ-II-es dugó tönkreteszi az RJ-45-ös 
végpontot! (IP telefon esetén ilyen probléma nem merül fel.) 

Egy rendszer tervezésekor fontos a megfelelő kábel kiválasz- 
tása. Ez egyrészt jelenti a kábel típust/fajtát, tehát hogy a 
csavart érpár milyen árnyékolással rendelkezzen, másrészt a ká- 
bel kategóriát. 

Ami a kábel kategóriát illeti, Cat5/Cat5e-nél gyengébb ká- 
belt sehol sem használunk. Ennéljobb minőségű kábel haszná- 
latát a beruházás időállóságával szokták indokolni, ami az adott 
esetben megfontolás tárgyát képezi. 

Az árnyékolás tekintetében országonként eltérő a hozzáállás. 
Néhány példa: 


. USA: elég az UTP, mert az megfelel. 
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2.17. ábra. Strukturált kábelezés 


" Németország: legyen árnyékolt, biztos ami biztos. 


. Magyarország: UTP, mert az olcsóbb (de árnyékolt, ha 
német érdekeltségű a cég) 


Műszakilag alapesetben teljesen megfelelő az UTP, viszont 
sok elektromos zajjal terhelt (például ipari) környezetben, il- 
letve olyan környezetben, ahol éppen a hálózat elektromágneses 
sugárzása okozhat gondot, megfontolandó valamilyen árnyékolt 
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2.18. ábra. Elemek a strukturált hálózatban 


megoldás választása. 

Ha az árnyékolás mellett döntünk, akkor annak úgy van ér- 
telme, ha az egész rendszerre kiterjed, tehát falkábel, csatlako- 
zók, patchkábelek. Fontos, hogy az árnyékoló rendszert földelni 
kell! 


2.2.1. — Tervezési szabályok 


Egy strukturált hálózat megtervezéséhez a tárgy kereteit meg- 
haladó ismeret és jártasság szükséges, az alábbiakban csak tájé- 
koztató jelleggel közöljük a Krone rendszer tervezési szabályai- 
nak kivonatát. 


Csatlakozók száma: 


- Fali csatlakozó: 


- 1 munkahely / 10 négyzetméter 
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x 2 csatlakozó / munkahely (telefon 4 LAN) 

x 2 tartalék csatlakozó / szoba (vagy: 41095) 
például: iroda 2000 négyzetméter — 220 dupla 
csatlakozó 


- . Padlódoboz: 


X 1 munkahely / 10 négyzetméter 

x 2 csatlakozó / munkahely (telefon 4 LAN) 

x 2 tartalék csatlakozó / szoba (vagy: 41092) 
A végpontoknak 1/3-a nem hozzáférhető az asz- 
talok és szekrények miatt! 


" Port szám és a rendezók szükséges mérete: 


Általában 24 és 32 portos RJ 45-ös felületű patch pa- 
nelt használunk. Leginkább 24 portosat, mert akkor 
sokkal kezelhetőbb a szekrény. 


A rendezőszekrények magassága a kiszolgálandó vég- 
pontok számától függ, az egysége a rack unit" Min- 


den két patch panel után egy kábelterelőt (gyűrűs 
panel) kell tervezni a kezelhetőség érdekében. 


A szükséges aktív eszközöket, szünetmentes tápegy- 
ségeket, villamos-hálózati csatlakozókat, esetleg szer- 
verek helyigényét is be kell tervezni a rendező szek- 
rények magasságába. Ügyeljünk a szükséges hűtés 
betervezésére is! Szükséges lehet a hűtő levegő szű- 
rése, a por ugyanis tönkreteheti az aktív eszközöket! 


Fontos a szekrény szélessége is, lehetőleg 800 mm szé- 
leset tervezzünk, hogy legyen hely a patch kábelek 
függőleges elvezetésére! 


Kábelhosszak: 


"31 rack unit (rövidítve 1U) — 44.45 mm (1.75 inch) 
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- Szigorú szabály EIA/TIA 568 és ISO/IEC 118021: 
Minden link (patch paneltől az aljzatig) kevesebb le- 
gyen mint 90 m! 


— Egy végpont kábelezésének a hossza — 
az épület szintjeinek belmagassága -t 
a rendező és a gerinc közötti nyomvonal hossza tk 
a kábel gerincen futásának hossza 
a szoba hossza t 
a szobában való ráhagyás -T 
1,5 m ráhagyás a bekötésnél 


Patch kábel hossza: 


— Szigorú szabály EIA/TIA 568 és ISO/IEC 118021: 
Minden channel (switch - patch kábel - patch pa- 
nel - falikábel - aljzat - patch kábel - számítógép) 
kevesebb kell legyen, mint 100 méter. 


— A rendező oldali patch kábel minimum 1 m, a számí- 
tógép lengőkábele maximum 9m"". 


Struktúra meghatározása 


— Mindig kellő biztonsági távolsággal tervezzünk 
— Megfelelő helyekre tervezzük a nyomvonalakat 
— Kellő távolság az erősáramú hálózattól 


— Csillag topológiával tervezzünk 


2 Vegyük észre, hogy a legfeljebb 100 méter szegmenshosszból legfeljebb 
1l0m lehet patch kábel és legfeljebb 90 m falikábel. Ez azért van, mert a 
falkábel és a patch kábel különböző" felépítésű, a patch kábel hajlékonyabb, 
de kedvezőtlenebbek a villamos jellemzői. 
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2.3.  Vezetéknélküli helyi hálózatok 


Ez az alfejezet egykori hallgatóm, Lugosi Zoltán szakdolgoza- 
tának [39] felhasználásával készült. A téma iránt mélyebben 
érdeklődőknek ajánljuk: [5] 


2.3.1. — Vezetéknélküli helyi hálózatok alapvető kér- 
dései 


A következő kérdésekkel fogunk foglalkozni: Milyen vezetéknél- 
küli átviteli megoldások léteznek? Milyen problémák adódnak a 
vezetéknélküli átvitelből és hogyan tudunk ellenük védekezni? 
Milyen frekvenciasávokat és milyen modulációs megoldásokat 
használhatunk? 


Vezetéknélküli átviteli megoldások 


Vezetéknélküli számítógép-hálózathoz szükséges átvitelre a kö- 
vetkező megoldások léteznek: 


. Optikai úton: 


- . Infra 
- Laser 


- Bluetooth egyes változatai 
. Rádiócsatornán keresztüli 


- Bluetooth 

- . HiperLAN/2 

- IEEE 802.11 és változatai 

- IEEE 802.16 (hivatalosan Wireless MAN) 

- PAN megoldások, például: IEEE 802.15 
(GSM adatcsatorna, GPRS, EDGE, HSDPA) 
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Az optikai megoldásokkal egyáltalán nem foglalkozunk, a 
WLAN-ok közül is csak néhánnyal. 

Mobilitás szempontjából a 2.19. ábrán látható módon cso- 
portosíthatjuk a jellegzetesebb megoldásokat. 


Mobilitás 


peep 


u 


Séta j Járm 


4 WLAN / 





Fix 
G rendszerek 


3G rendszerek 


Beltéri alk. 3 Kültéri alkalmazások 


í2 § NN Í LAN 
EZ (4. Bluetooth 














0.1 l 10 100 Mbit/s 


2.19. ábra. Egyes hálózati megoldások mobilitás és átviteli se- 
besség jellemzői 


A rádiós átvitel problémái 


A rádiós hálózatok működését negatívan befolyásoló tényezők a 
következők: 


Fading Többutas terjedésnél ellentétes fázisban érkezhet meg 
a direkt és a visszavert hullám, amik igen erősen gyengítik 
egymást. Lásd a 2.20. ábrán. 
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Védekezés: a rádiós átvitelnél kezeljük, például: térbeli 


diverziti (diversity) vétel (több vevő használata eltérő el- 


bye 


helyezkedésű antennákkal). 


Zaj Nem a rendszerből származó (véletlenszerű) villamos jel. 
Védekezés: hibajavító kódolással. 


Interferencia (vagy ütközés) más állomás adásával 
Védekezés: szórt spektrumú megoldások 


Rálátás hiánya Az adó és a vevő között a Fresnel-zóna [36] 
nem (teljesen) üres. 


Védekezés: visszavert jel használata "feljavítással": szórt 
spektrum 


Adó 





közvetlen vétel 








reflektált vétel 


2.20. ábra. Fading kialakulása 
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Felhasználható frekvenciasávok 
Két alkalmazott frekvenciasáv létezik: 
. ISM (Industrial, Scientific and Medical) 
-  2,4-2,4835 GHZz/14 előre kijelölt frekvencia 
- Földrajzi régiók szerint különbözhet. 
(Európa, USA, Japán, Franciaország, Spanyolország) 
. UNII (Unlicenced National Information Infrastructure) 


- . 5,150-5,250 GHZz/12 előre kijelölt frekvencia 


- Földrajzi régiók szerint különbözhet. 
(Európa, USA, Japán, Franciaország, Spanyolország) 


Szórt spektrumú modulációs eljárások 
Három szórt spektrumú megoldás létezik: 


. DSSS (Direct Seguence Spread Spectrum) 
" FHSS ( Freguency Hopping Spread Spectrum) 
" CDMA (Code Division Multiple Access) 


Mindhárom megoldásnál a jel spektrumát mintegy , szétke- 
nik". Az átviendő jel spektrumát valamilyen transzformációval 
az eredetinek több tízszeresére kiszélesítik, és kisebb teljesít- 
ménysűrűséggel viszik át. Az általunk tárgyalt rendszerek a 
DSSS és az FHSS mellett nem a CDMA-t, hanem az OFDM-et 
(Orthogonal Freguency Division Multiplexing) használják még, 
ami nem szórt spektrumú megoldás. 


DSSS (Direct Seguence Spread Spectrum) esetén chipek" meg- 
felelő sorozatával kódoljuk az egyest és a nullát. A 2.21. áb- 
rán láthatunk egy példát. Ha néhány chip invertálódik is 


25 
a bitnél kisebb adategység 
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valamilyen zaj miatt, nagy valószínűséggel még felismer- 
hető lesz a bit. 


Az "T"-es kódolása: 
H1-1-41-1-1-1-t1-41-41-1I -I-I 


A "0" kódolása ennek az inverze. 


Bináris adat 








L1 18 I l 
Chip kóddal előállított 
DBPSK jelsorozat 


2.21. ábra. Direct Seguence Spread Spectrum 


Ezzel a megoldással jócskán megnőtt a szükséges sávszé- 
lesség. Három vivő fér bele oldalsávjaival (22 MHz) a ren- 
delkezésre álló tartományba: 2.22. ábra. 


Három különböző frekvenciával már lefedhető úgy a sík, 
hogy a szomszédosak minden oldalról különböznek, így 
elkerülhető a zavartatás, az interferencia minimális lesz: 
2.23. ábra. 


FHSS (Freguency Hopping Spread Spectrum) rendszerben a 
frekvenciasávban 75db vivőfrekvenciát definiálunk. Az 
adó egy ál véletlen generátorral választja ki közülük, hogy 
melyiken adjon. (2.24. ábra). Természetesen a vevő ugyan- 
azt az álvéletlen generátort használja, és azonos értékről 
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csatorna vivő 


25MHz Tal 
———— 














2400 GHz 2484 GHz 
F 2412 GHz F,-2,437 GHz F.-2462 GHz 


1. csatorna 6. csatorna 11. csatorna 


2.22. ábra. Vivőfrekvenciák és oldalsávjaik. 


f — —24I2GHz f—2,437GHz f—2,462GHz 





2.23. ábra. Frekvencia újrahasznosítás (DSSS) 


indulnak." Egy adott területen egyszerre adni kívánó ál- 


b. 


lomások nagy valószínűséggel eltérő frekvenciákat válasz- 


7 Ha az álvéletlen generátor egy kriptográfiailag erős véletlenszám ge- 
nerátor, azaz az éppen használt frekvenciából nem lehet előrejelezni a kö- 
vetkezőt, akkor a megoldás katonai alkalmazásokhoz is kiváló, hiszen az 
eredményes zavaráshoz a teljes sávban kell zavaró jelet adni, ami lényege- 
sen nagyobb energiát igényel, mint a kommunikációhoz használt adás. 
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tanak (feltéve, hogy nincsenek túl sokan). 


I áció fs . 
"oras 1ó  [-e] Modulátor Ep-— FHSS jel 
szintetizátor 


h 


2400-2483,5MHz-es ésén 
tartományban 75 


kijelölt frekvencia. 


Vivő , 
frekvencia 


E 








2.24. ábra. Freguency Hopping Spread Spectrum 


OFDM (Orthogonal Freguency Division Multiplexing) esetén 


a 2.25. ábrán bemutatott megoldást alkalmazzuk. Legfe- 
lül egy négyszög jel és a spektruma látható. Alatta ta- 
lálható - viszonyítási alapként - egy klasszikus frekvencia 
osztásos multiplex (FDM - Freguency Division Multiplex) 
jel spektruma. Látható, hogy a szomszédos csatornák vi- 
vőfrekvenciái csak annyira közelíthetők egymáshoz, hogy 
az átlapolódás energiatartalma olyan kicsi legyen, hogy a 
dekódolás hibamentesen elvégezhető legyen. Az ábra har- 
madik része egy ortogonális frekvencia osztásos multiplex 
(OFDM) jel frekvenciatartománybeli , összerakását" mu- 
tatja. Miért , tolhatók egymásba" ennyire az egyes csa- 
tornák vivőfrekvenciái? Az eljárás alapja az ortogonális 
frekvenciák használata. Ortogonálisak azok a frekvenciák, 
amelyekre fennáll az FR, — (F, 1 n/7) kapcsolat. Tekint- 
sük ezeknek a frekvenciáknak a spektrumát: 2.26. ábra. 
Az egyes alvivők középfrekvenciáján a többi jel spektruma 
mindig 0 értéket vesz fel. Ez a magyarázata annak, hogy 
miért , tolhatók egymásba" a klasszikus FDM-hez képest 
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Egy időtartománybeli 


HM. jel spektruma. 


Klasszikus frekvencia 
osztásos multiplex (FDM) 
jel spektruma. 


Ortogonális, frekvencia 
osztásos multiplex (OFDM) 
jel spektruma. 








2.25. ábra. Orthogonal Freguency Division Multiplexing 


sokkal sűrűbben az OFDM vivőfrekvenciái. 


Az OFDM előnyei: 


. jobb spektrum kihasználás 

" külső zavarok elleni hatásosabb védelem 

" közvetlen rálátást nem igénylő (non-line-of-sight) mű- 
ködés 


2.3.2. — Vezetéknélküli hálózati termékek fontosabb 
jellemzői 


Ismerjünk meg néhány vezetéknélküli hálózati megoldás fonto- 
sabb jellemzőit! 
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2.26. ábra. Ortogonális alvivők spektruma 


e Bluetooth 


- "Ez egy PAN megoldás 

- Bluetooth Special Interest Group fejlesztette 
- Alacsony fogyasztású eszközök 

- , Maximum 8 eszköz egy hálózatban 

- Rövid távolságokra (Cl 10 méter) 

- . Számítógép és kézi eszközök között 

- Alacsony sebességű (1 Mbps) 

- ISM frekvenciatartományban működik 


- . Pont-pont, pont-multipont összeköttetés 
" HiperLAN/2 (High Performance Radio LAN) 


- . European Telecommunications Standards Institute 
(ETSD fejlesztése 
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- Áthidalható távolság 100 méter 
- Átviteli sebesség 54 Mbps 
- Mind az ISM, mind az UNII frekvenciasávban 


- . OFDM modulációs mód 
e IEEE 802.11.x változatok fóbb paraméterei 


- IEEE 802.11: 2 Mbps, 300 m, ISM, DSSS 
- . IEEE 802.11b: 11 Mbps, 100 m, ISM, DSSS 
- . IEEE 802.1Ila: 54 Mbps, 200 m, UNII, OFDM 


- IEEE 802.Ilg: 54 Mbps, 200 m, ISM, OFDM, kom- 
patibilis az IEEE 802.11b-vei 


2.3.3. Az IEEE 802.11 szabványcsalád 


Ezekkel egy kicsit részletesebben is megismerkedünk. 


2,4 GHz-es WLAN szabványok 
e IEEE 802.11 


— DSSS vagy FHSS moduláció 


— 1-2-3 Mbit/s bruttó átviteli sebesség 

e IEEE 802.11b (Wi-Fi) High Speed Wireless LAN 
— DSSS moduláció 
— 11 Mbit/s bruttó átviteli sebesség 

e IEEE 8302.Ilg Very high speed Wireless LAN 


— OFDM moduláció 
— 54 Mbit/s bruttó átviteli sebesség 
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5 GHz-es WLAN szabvány 
. IEEE 802.1la High Speed Wireless LAN 


-  OFDM (64 FET - 54 alvivő) 
- 54 Mbit/s bruttó átviteli sebesség 


3. fejezet 


Internet protokollkészlet 


Először is tisztázzunk néhány fogalmat! Az internet jelentése: 
összekapcsolt hálózat. Az Internet egyetlen világméretű nyilvá- 
nos IP alapú internet. Az intranet internet technológiát hasz- 
náló intézményi belső hálózat. Az internet protokollkészletbe 
(internet protocol stack) tartozó legfontosabb protokollok: 


IP (Internet Protocol, magyarul: internet protokoll") 
Az IP egy nem megbízható datagram! szolgálatot bizto- 
sít forrás és célgép között, függetlenül attól, hogy ezek 
hol helyezkednek el (azonos, szomszédos, vagy egymástól 
távoli hálózatban). 


TCP (ITransmission Control Protocol) 
A TCP az IP-t felhasználva két végpont közötti megbíz- 
ható kétirányú bájtfolyam átvitelt biztosít. Ehhez a két 
végpont között kapcsolatot épít fel, amit az átvitel végén 
le kell bontani. 


UDP (User Datagram Protocol) 
Az UDP szintén az IP-re építve összeköttetés nélküli (itt 


" Figyeljünk oda az eltérő helyesírásra! 
? A csomag speciális neve az internet protokollkészletben. 
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nincs kapcsolat felépítés, bontás) végpontok közti nem 
megbízható datagram szolgáltatást nyújt a felhasználók- 
nak. 


ICMP (Internet Control Message Protocol) 
Az ICMP az IP szolgálati közleményeit hordozza (szintén 
az IP-re építve) két IP-t használó állomás között. 


A 3.1. ábrán megfigyelhetjük a felsorolt protokollok elhe- 
lyezkedését a TCP/IP modellben. A hordozó rétegre épül az 
IP, erre pedig a TCP és az UDP. Az ICMP-t az általunk hasz- 
nált , egysíkos" számítástechnikai architektúrában az IP réteg 
részének tekintjük." Először ezzel a négy protokollal ismerke- 
dünk meg. 


Alkalmazások 


FIP § HETP DNS 








! SMTP 





sszséz 1 





EGE I I I UDP 











IP 1cmp) 


Hordozó (pl. LAN, MAN, WAN, WLAN) 1 


3.1. ábra. A TCP/IP protokollcsalád 


Az internet protokollkészlet elemeinek (és sok más számí- 
tástechnikával, hálózattal kapcsolatos protokollnak) a definíci- 
óját az RFC-kben találjuk meg. Az RFC a Reguest For Com- 
ments rövidítése. Ezek a dokumentumok elérhetők például a 
http://rfc.net webcímen. Az egyes protokolloknál a további- 
akban mindig megadjuk az azt eredetileg definiáló RFC számát 





JA távközlési architektúrában pedig egy külön úgynevezett vezérlő 
(control) síkon helyezkedik el. 
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is. 

Ajánlott irodalom: Mivel az RFC-k nem túl olvasmányo- 
sak, az internet protokollkészlethez ajánlunk néhány könyvet. 
Elsőként Comer könyvének első kötetét [4] ajánljuk, ami alap- 
ján e fejezet is készült. Szintén jól használható mű [19]. Nem 
olvasmányos, mivel kézikönyv [14]. Magyar nyelvű és újabb 
könyv: [18]. 


3.1. Internet Protocol 


Az IP protokollt eredetileg az RFC 791-ben definiálták. 


3.1.1. Az IP címek 
Az IP címek felépítése 


Az IP-nek két, bárhol elhelyezkedő számítógép között képesnek 
kell lennie adatokat szállítani. Ehhez mindenek előtt megfelelő 
címzésre van szüksége. Amikor egy levelet postán szeretnénk 
elküldeni valakinek, akkor meg kell adnunk, hogy a címzett mely 
ország mely városában, ott milyen utcában és hányas szám alatt 
lakik. A címzés tehát hierarchikus. 

Az IP 32 bitet használ egy állomás megcímzésére. A hie- 
rarchikus címzés két szinten valósul meg. A cím első része a 
hálózatcím (network address) kiválasztja azt a hálózatot, ame- 
lyikre az állomás csatlakozik, a második része a gépcím (host 
address) pedig a cím első része által kiválasztott hálózaton belül 
azonosítja a gépet. 

A protokoll tervezői úgy döntöttek, hogy több lehetőséget 
adnak arra, hogy hol legyen a két rész határa a 32 biten be- 
lül. Annak ismeretében alakították ki az IP cím osztályokat, 
hogy nagy szervezetből kevés van, közepesből jóval több, kicsi- 
ből pedig kifejezetten sok. A cím első néhány bitje meghatá- 
rozza, hogy az IP cím melyik osztályba tartozik (A, B, C, D, 
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E). A 3.2. ábra megmutatja, hogy melyik osztályban mekkora 
rész jut a hálózat, illetve a gép címének megadására." 
































0 78 31 
AJTO NETWwoRrKk ! HOST ] 
[9] 15 16 31 
a izé gi cS 
B/10 NETWORK ] HOST 
0 ha ea Egg Szhee za kta set emg azaat zá 2324 MESE 31 
GI11B NETWORK — HOST ] 
9] 31 
D j 11 10 Me  Muiticast address j 
stl 31 
E 1 1 1 1 0 Reéserved for future use 


3.2. ábra. Az IP címek felépítése 


Speciális jelentése van, ha egy IP cím host részében minden 
bit 0 értékű: ez az egész hálózatot jelentő network address; 
hasonlóan annak is, ha a host részben minden bit 1 értékű: 
ez az adott IP hálózatba tartozó összes gépet jelentő broadcast 
address. 

Az IP címek kanonikus (egyezményes, szabványos) írásmódja 
a következő: A 32 bites címeket 4 db oktettref bontjuk, majd 
ezeket tízes számrendszerben, egymástól ponttal elválasztva Ír- 
juk le. Például: 193.224.128.1. Ez a cím binárisan 110-val kez- 
dődik, mert a 193 kettes számrendszerben: 11000001. Tehát ez 
a cím , C" osztályú. A hálózatcím 3 oktett, a gépcím 1 oktett." 


! Az osztályokon alapuló c/assful addressing ma már részben csak törté- 
neti jelentőségű, lásd: 4.1.6. 

JA bájt megnevezése a TCP/IP protokollcsalád fogalomtárában. Hang- 
súlyozottan 8 bitet jelent. 

"Vegyük észre, hogy milyen kényelmes az, hogy az összes IP cím osz- 
tályban a két rész határa mindig oktett határra esik! 
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Az IP hálózatcímek kiosztása 


Az IP hálózatcímek kiosztását legfelső szinten az Internet Assig- 
ned Number Authority (IANA) [27] végzi. Érdeklődők bővebben 
olvashatnak a témáról az alábbi weboldalon: [23] 

A fenti lapról elérhető, jelenleg kiosztott tartományok jelölé- 
sének megértéséhez szükséges a 4.1.6-ban tárgyalt CIDR jelölés 
ismerete. 

Egyelőre annyit említünk meg, hogy vannak privát, más szó- 
val nem publikus IP cím tartományok, amelyeket bárki használ- 
hat, anélkül, hogy igényelné, de ezek használatával csak a saját 
intézményén belül tud kommunikálni, a világ többi része felé 
nem. (A címfordítástól eltekintve, de ahhoz is kell egy darab 
publikus IP cím.) Ezekből az érdeklődő hallgatóink bátran oszt- 
hatnak a saját otthoni számítógépeik számára IP címeket, ha 
hálózatba szeretnék kötni őket. Az RFC 1918 szerint ilyenek: 


," a 10.0.0.0 , A" osztályú hálózat 


e a 172.16.0.0-tól 172.31.0.0-ig terjedő 16 darab , B" osztályú 
hálózat 


" és a 192.168.0.0-tól 192.168.255.0-ig terjedő 256 db ,C" 
osztályú hálózat 


3.1.2. Az IP datagramok felépítése és használata 


A 5. oldalon található 1.2. ábrán elviekben már láttuk, hogyan 
történik az elküldendő információ beágyazása és kibontása. A 
protokoll adategység (PDU) két részből áll, a protokoll vezérlő 
információból (PCI) és a szolgáltatás adategységéből (SDU). A 
következőkben az IP datagram felépítésével fogunk részletesen 
megismerkedni. 


" NAT: Network Address Translation - e jegyzet keretében bővebben 
nem tudunk vele foglalkozni. 
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6 19 24 31 


a 1 





OPTIONS ÚF ANY) PADDING 


3.3. ábra. IP datagram felépítése 


A 3.3. ábrán feltüntettük egy IP datagram összes lehetséges 
mezőjét. Az egyes mezők nevét rövidítettük, ezeknek megadjuk 
a teljes nevét, valamint megadjuk az egyes mezők funkcióját is, 
közben lépésről lépésre megismerkedünk az internet protokoll 
működésével. 


Version verzió szám 
Értéke: 0100, mivel az IP 4-es verziójáról van szó. 
(A későbbiekben megismerendő IPv6 esetén értéke: 0110) 


IHL (Internet Header Length) fejrész hossza 
1 egység — 32 bit (4 oktett), ezért a fejrész oktettekben 
mért hosszának oszthatónak kell lennie 4-gyel. Tipikus 
értéke az 5; ha vannak opciók a fejrész végén, akkor lehet 
6 vagy több. 


Type of Service szolgálat típusa 
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Ez a mező további almezőkre bomlik, ráadásul az értel- 
mezése változott, ezért külön foglalkozunk vele. 


Total Length a datagram teljes hossza 


Identification azonosítás 
Szétdarabolt keretek esetén azonosítja az összetartozó tö- 
redékeket. (A tördeléssel is külön foglalkozunk.) 


Flags jelzőbitek 
Három bitből áll, ezek rendre: 


0 (reserved) kihasználatlan 
Értéke kötelezően 0. 


DF (Do not Fragment) ne tördeld 
0: szabad tördelni 
1: nem szabad tördelni 


MF (More Fragments) van még töredék 
0: ez az utolsó töredék 
1: ez még nem az utolsó töredék 


Fragment Offset töredék eltolás 
Tördelés esetén megadja, hogy az adott töredék adatré- 
szében a kezdő bájt hányadik volt az eredeti datagram 
adatrészében. Mivel a mérete 13 bit, ezért 8 oktettes egy- 
ségekben értendő! 


Time to Live élettartam 

Legfeljebb 255 lehet az értéke, minden csomópontnál csök- 
kentik az értékét a várakozással eltöltött másodpercek szá- 
mával, de legalább 1-gyel. (A gyakorlatban 1-gyel.) Ha 
0-ra csökken az értéke, a csomagot eldobják. Ennek a 
célja az, hogy ha esetleg az útvonalválasztás hibája mi- 
att egy csomag , eltéved", ne maradjon korlátlanul hosszú 
ideig a hálózatban (erőforrás pazarlás). 
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Protocol protokoll 
Megadja, hogy az IP felett milyen protokoll helyezkedik 
el. (pl. TCP, UDP, ICMP) 


Header Checksum a fejrész ellenőrző összege 
Source Address forrás IP címe 
Destination Address cél IP címe 


Options opciók 
Szerepelhetnek egyéb beállítások is, de nem feltétlenül 
vannak. Ha vannak, a méretük nem feltétlenül a 4 ok- 
tett egész számú többszöröse. 


Padding helykitöltés 
Mérete I, 2 vagy 3 oktett lehet. Azért szükséges, mert az 
, IHL" egysége 32 bit, így a fejrész méretét mindig ki kell 
egészíteni annak többszörösére. 


Data adatok 
Itt található beágyazva az IP fölötti protokoll adategy- 
sége. 


Most visszatérünk a Type of Service mezőre, utána pedig a 
datagramok tördelésével fogunk foglalkozni. 


A Type of Service mező régi jelentése 


Már az IP protokoll tervezésekor is gondoltak arra, hogy attól 
függően, hogy mit szállít egy datagram, más-más elbánásra le- 
het szüksége. A Type of Service mezőt arra tervezték, hogy 
ezt támogassa. Az eredeti, RFC 791-ben leírt mezőit látjuk 
a 3.4. ábrán. 

Ezek értelmezése a következő: 


3.1. 


INTERNET PROTOCOL 79 


PRI DTR 00 


3.4. ábra. A , Type of Service" mező almezői (RFC 791 szerint) 


Az első három bit a prioritás (elsőbbség) megadására szol- 


r4 


gál. 


AD, TésR bitek közül legfeljebb két darab értéke lehet 1- 
es. Amelyik értéke 1-es, az útvonalválasztók a datagram 
továbbítása során annak a jellemzőnek az értékét igye- 
keznek optimalizálni, de garanciát nem vállalnak. Úgy 
nevezik ezt, hogy a hálózat , best effort" jellegű. 


D (Delay) I-es értéke azt jelenti, hogy a késleltetés minél 
kisebb értéke a fontos számunkra. 

T (Throughput) az időegységenkénti minél több adat át- 
vitelét jelenti. 

R (Reliability) pedig a megbízhatóságot, hibamentessé- 
get kéri. 


A 3.1. táblázatban látunk néhány példát, hogy a külön- 
böző adatfajták mire érzékenyek a három jellemző közül. 


Az utolsó két bitet eredetileg nem használták, értékük 
kötelezően 0. 


Azonban a routerek (útvonalválasztók) általában nem vet- 
ték (és legtöbbször ma sem veszik) figyelembe a Type of Service 
mezőben található értékeket. 


A Type of Service mező új jelentése 


A Type of Service mező használatának megváltoztatására több- 
féle javaslat is született: 
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adat-]! hang ] tömörített ! videó ! tömörített 


[fájl I hang videó 





; 7 Í 
I! delay [a k [ok 4 j 





Lt hroughput ET HK ] Hc-ANRÉRN AE. 





[Tr eliability ] a ] : [a 


3.1. táblázat. Mire érzékenyek az egyes tartalmak? 


RFC 1349 A Type of Service oktettben hagyjuk meg a három 
bites prioritást, és a következő három bites mezőt (koráb- 
ban DTR) TOS néven bővítsük ki még egy bittel, amivel 
a költségek minimalizálását lehet kérni. (Az utolsó bitet 
pedig 0-ra kell állítani.) 


RFC 1455 Az RFC 1349-ben definiált négy bites TOS mező 
(eddig nem megengedett) 1111 értéke jelentse azt, hogy a 
továbbítás során olyan útvonal választását kérjük, ami a 
datagram lehallgatása ellen legjobban véd. (Például rá- 
diós helyett vezetékes csatornán vigyük át, ha lehet.) 


RFC 2474 Használjuk a 8 bitből a baloldali 6 bitet (RFC 791 
szerinti prioritás és TDR) különleges kiszolgálás" (Differ- 
entiated Services, szó szerint: megkülönböztetett szolgál- 
tatások) nyújtása érdekében! Ezt a 6 bitet DSCP-nek 
(differentiated services codepoint) nevezik. 


RFC 2481 Használjuk az utolsó két bitet Explicit Congestion 
Notification (ECN) célokra. Ennek a belső megoldása vál- 
tozott RFC 3168-ban, ezért bővebben nem ismertetjük. 


RFC 3168 Használjuk az utolsó két bitet Explicit Congestion 
Notification célokra, de más módon, mint RFC 2481 ja- 
vasolta. 


"Ezt a fordítást [18] használja. 


gj. INTERNET PROTOCOL 81 


Tehát a jelenlegi állás szerint a Type of Service mező első 6 
bitje DSCP, az utolsó két bitje pedig ECN. (3.5. ábra) Ezekkel 
e jegyzet keretében mélyebben nem foglalkozunk. 














DSCP ECN 





3.5. ábra. A , Type of Service" mező almezőinek új jelentése 


Datagram tördelése 


A tördelés működését egy példán keresztül mutatjuk be. 
Feladat: Egy 1000 oktett méretű IP datagramot tördeljünk 
a lehető legkevesebb részre úgy, hogy egy darabja maximum 500 
oktett méretű lehet." Adatok: IHL — 6, DF — 0. Hány darabra 
kell tördelni? A keletkező datagram darabokban mi lesz a 7otal 
Length, a Fragment Offset és a Flags mezők értéke? 
Megoldás: A datagramot 3 darabra kell tördelni: 3.6. ábra. 


o 23 24 495 496 967 968 999 











4 3 4 Á 
o 23.24 495 
4 MA 3 
Ms yzásék 708 A 
24 472 
0 23:24 495 
4— ik 4 
4 472 
o 23 24 55 
d út A 


24 32 


3.6. ábra. Az IP datagram tördelése 


" Ezt úgy hívják, hogy: MTU (maximum transmission unit). 
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A 24 oktett méretű fejrészt mindhárom új datagram fejré- 
szébe bemásoljuk. Egy datagram mérete legfeljebb 500 oktett 
lehet. Legfeljebb 500 - 24 — 476 oktett adat kerülhetne egy 
datagramba, de sajnos ez nem osztható 8-cal. A 472 a lehető 
legnagyobb 8-cal osztható szám, ami 476-nál nem nagyobb. Az 
1000 oktett méretű eredeti datagram 1000 — 24 — 976 adat 
oktettjéből tehát 472-t elhelyezünk az első, majd a második da- 
tagramba, így 976— (2"472) — 32 adat oktett kerül a harmadik 
datagramba. Az első két datagram mérete: 472 -- 24 — 496 ok- 
tett, a harmadiké: 32- 24 — 56 oktett. A fragment offset mező 
értéke rendre: 0, 472/8 — 59, 2 " 472/8 — 118. A datagram 
darabok továbbra is tördelhetők maradnak; a harmadik után 
pedig már nincs további töredék. Az eredményt a 3.2. táblázat- 
ban foglaltuk össze. 





J ú ] FI ags ] Fragment Offset ! Total Length 
I 1. datagram ] 001 0 496 
b 2. datagram [0 1 [ 59. ] 196 
[ 3. datagram [ 000 [118 I 56 ] 






































3.2. táblázat. IP datagram tördeléséről szóló feladat megoldása 


3.1.3. . Amivel az IP nem foglalkozik 


Most, hogy már ismerjük az IP működését, vizsgáljuk meg, mire 
van még szükség rajta kívül ahhoz, hogy az alkalmazásaink egy- 
mással kommunikálni tudjanak. 


Megbízható átvitel 


Az IP fejrésze tartalmaz ugyan ellenőrző összeget, de ez csak a 
fejrészre vonatkozik, ebből következik, hogy a datagram adat- 
részének sérülését nem képes detektálni. 


3.1. INTERNET PROTOCOL 83 


Az átvitel során a datagramokkal a következő - az IP által 
nem kezelt - problémák fordulhatnak elő: 


. tartalom megsérülhet 
e. datagram elveszhet 


. a datagramok sorrendje felcserélődhet 


e 


. datagram megkettőződhet 


Szükség van tehát olyan protokollra, ami az IP-re építve 
megbízható átvitelt nyújt. 


Kapcsolatok azonosítása 


A 3.7. ábrán egy webszerver és két kliens gép látható. Természe- 
tesen annak sem lehet akadálya, hogy egy kliens gépről egyide- 
jűleg két böngészővel is elérjük ugyanazt a szervert. Ekkor sem 
szabad a két weblap tartalmának összekeverednie. Márpedig 
a két IP cím azonos az egy gép két külön böngésző esetében! 
Tehát szükséges a kapcsolatok azonosítása. Erre természete- 
sen nem csupán két azonos szolgáltatás, hanem különbözőek 
(például egy fájl letöltés és egy távoli bejelentkezés) esetén is 
ugyanígy szükség van. Sőt, már a kapcsolat létrejöttekor egyér- 
telműen ki kell jelölni, hogy milyen szolgáltatáshoz szeretnénk 
csatlakozni. 


Szolgálati közlemények 


Ezt ugyan a felhasználók nem igénylik, de teljesen nyilvánvaló, 
hogy szükség van szolgálati közlemények továbbítására is. Az 
OSI modell fogalmaival élve, időnként egy adott réteg entitá- 
sainak egymással is kommunikálniuk kell, például valamilyen 
hiba esetén. A TCP/IP modellben nem használjuk az entitás 
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rs1.sze.hu 
193.224.128.1 


c607-1 .sze.hu 
193,224.130.102 









c607-2.szec.hu 
193.224.130.99 


80-as port: 
HTTP kiszolgáló 


3.7. ábra. Példa egy TCP kapcsolatra 


kifejezést, inkább a protocol stack" belső kommunikációjáról 
beszélünk. 


3.2.  Transmission Control Protocol 


A Transmission Control Protocolt az RFC 793-ban definiálták. 
A TCP megoldja a megbízható átvitelt is, és a kapcsolatok azo- 
nosítását is. 

Egy kapcsolat két végpontja között megbízható átvitelt biz- 
tosít kétirányú adatforgalommal: ami az egyik végponton elin- 
dul, a másikon pontosan annak, és ugyanolyan sorrendben kell 
megjelennie. Olyan ez, mint két szivárgás mentes csővezeték: 
3.8. ábra. 

A hálózati kapcsolat végpontját pedig a portszám azonosítja. 
A portok mindig konkrét szolgáltatást azonosítanak. Például a 
80-as porton web kiszolgáló, a 22-es porton ssh szerver műkö- 
dik, stb. Egy kapcsolatot pedig 4 szám azonosít egyértelműen: 


" Az internet protokollkészlet implementációját értjük alatta. 
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egyik EGT se SSE áta ztás másik 
VÉgDONI ee re——.. : Yv épan 
E a 1f—— 


3.8. ábra. TCP kapcsolat modellje 


a küldő és a címzett gép IP címe, valamint a küldő és a címzett 
gépen a portszámok. (így ha például ugyanazon két gép kö- 
zött van két azonos szolgáltatást igénybe vevő kapcsolat, akkor 
a négyből három szám (a két IP cím és a szerver portszáma) 
megegyezik, de a negyedik alapján akkor is megkülönböztet- 


hető a két kapcsolat.) A portszámok kiosztásával majd később 
foglalkozunk: 5.1.l. 


3.2.1. A TCP szegmens felépítése 


Ismerjük meg most a TCP szegmens" felépítését! Emlékezzünk 
rá, hogy a beágyazás-kibontás elvének megfelelően, az egész 
TCP szegmens az IP datagram adatrészében utazik a hálóza- 
ton! 

A TCP szegmens felépítése a 3.9. ábrán látható. A TCP 
szegmens az alábbi mezőket tartalmazza: 


Source Port forrás port 
A portszám azon a gépen, ahonnan a szegmenst küldték. 


Destination Port cél port 
A portszám azon a gépen, ahova a szegmenst küldték. 


" Ez a TCP PDU-jának a megnevezése. (Mint ahogyan az IP PDU-ját 
datagramnak hívják.) 
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16 24 31 
same dee] 7 ve 


CHECKSUM URGENT POINTER 
OPTIONS (IF ANY) PÁDDING 
DATA 





3.9. ábra. TCP szegmens felépítése 


Seguence Number sorszám 
Az átvitel során az oktetteket sorszámozzuk. A sorszám 
megmutatja, hogy a szegmens adatmezőjének kezdő ok- 
tettje hányas sorszámot kapott. 


Acknowledgment Number nyugta 
Annak az oktettnek a sorszámát adja meg, amelyiket vár- 
ja; addig az összes nyugtázva van. 


Data Offset adatmező eltolás 
32 bites egységekben mérve megadja az adatmező kezde- 
tét a TCP szegmens kezdetéhez képest. Tulajdonképpen 
a fejrész hossza, mint IP-nél az IHL mező. 


Reserved későbbi használatra fenntartva 
Az RFC 793 szerint még a 4 bites Data Offset után kö- 
vetkező 6 bit nem volt használatban. Ez jobbról 2-vel 
csökkent RFC 3168 alapján. 
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Control bits vezérlőbitek 
RFC 793 szerint csak 6 darab volt, az RFC 3168 vezette be 
a CWR és az ECE vezérlőbiteket a korábban fenntartott 
6 bites terület végén. 
A vezérlőbiteknél mindig azok 1 értéke esetén áll fenn az, 
amit a nevük jelent. 


CWR (Congestion Window Reduced) - RFC 3168 
A torlódási ablakot szűkítették. Bővebben nem fog- 
lalkozunk vele. 

ECE (ECN-Echo) - RFC 3168 
Torlódásjelző visszhang. Bővebben ezzel sem foglal- 
kozunk. 

URG (urgent) 
A sürgős adat mutató érvényes. 

ACK (acknowledgment) 
A nyugta mező érvényes. 

PSH (push) 
Jelzi az adat késedelem nélküli továbbításának igé- 
nyét. 

RST (reset) 
Egy host összeomlása, vagy más okból összezavart 
összeköttetés helyreállítására szolgál, illetve ha egy 
porton semmilyen program sem figyel, akkor az adott 
portra megkísérelt kapcsolatfelépítés esetén mindjárt 
az első SYN csomagra RST a válasz. 

SYN (synchronize) 
Összeköttetés létesítésére szolgál. 

FIN (finish) 
Összeköttetés bontására szolgál. 


Window ablak 
Az ablakméretet adja meg. A megbízható átvitelhez szük- 
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séges nyugtázási mechanizmus használja, részletesen fog- 
lalkozunk vele. 


Checksum ellenőrző összeg 
A teljes szegmensre képezik. 


Urgent Pointer sürgős adat mutató 
A sürgős adat az adatfolyam menetét megszakítva a többi 
adatot megelőzve feldolgozandó adat. A sürgős adat az 
adatmező elejétől kezdődik, a mutató a sürgős adat után 
következő (már nem sürgős) adat kezdetére mutat. 


Options opciók 
Mint IP-nél. 


Padding helykitöltés 
Mint IP-nél. (A magyarázatban természetesen IHL he- 
lyett Data Offset értendő.) 


data adatok 
Itt található beágyazva a TCP fölötti protokoll adategy- 
sége. 


Az IP-vel szemben a TCP kapcsolat orientált protokoll, így 
nem véletlen, hogy a mezők jelentős részének a használata nem 
magyarázható meg kielégítően egy-két mondattal. Most egyen- 
ként megvizsgáljuk, hogyan történik a kapcsolat felépítése, a 
megbízható átvitel és a kapcsolat lebontása. 


3.2.2. TCP kapcsolatfelvétel 


Tegyük fel, hogy egy , A" állomás kapcsolatot szeretne kezdemé- 
nyezni egy ,, B" állomással. Az ,A" állomás létrehoz egy kapcso- 
lat struktúrát, amiben a kapcsolat paramétereit tárolja, majd 
összeállít egy TCP szegmenst a , B" számára: generál egy kezdő 
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sorszámot" (x), amit elhelyez a seguence number mezőben, va- 
lamint beállítja a SYN kódbit értékét 1-re; ezzel jelzi, hogy ez 
egy új kapcsolat. A szegmenst (az IP réteg segítségével) elküldi 
, B-nek. Kövessük ezt nyomon a 3.10. ábrán! A , SYN" feltün- 
tetése azt jelenti, hogy ennek a kódbitnek az értéke I, a seg — x 
önmagáért beszél. 


A B 

küld SYN, seg-x 
veszi 
küld 

veszi 
segzy, ackzxt1 

küld ACK, ackzyr1 

veszi 





3.10. ábra. TCP kapcsolatfelvétel 


Amikor a ,, B" állomáshoz megérkezik a kapcsolat kezdemé- 
nyezés, a , B" állomás is lefoglal egy kapcsolat struktúrát, ami- 
ben eltárolj értéket (és a továbbiakban ebben tartja nyil- 
ván a kapcsolat paramétereit). A , B" állomás összeállít egy 
válasz szegmenst. ,,B" is generál egy kezdő sorszámot (y) amit 
elhelyez a válasz szegmens seguence number mezőjében, és be- 


BA modern operációs rendszerek (például OpenBSD) kriptográfiailag 
erős véletlenszám generátort használnak, mert ha bármilyen módon elóre- 
jelezhető lenne a kezdő sorszám, az támadásra adna lehetőséget. 
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állítja a SYN kódbitet. Ezen kívül a szegmens acknowledgment 
number mezójébe az x § 1 értéket helyezi el" és beállítja az 
ACK kódbitet. Ezután elküldi a szegmenst , A"-nak. Összefog- 
lalva: , B" létrehozta az , A" fele irányuló kapcsolatra vonatkozó 
sorszámot (y) és nyugtázta az , A" által küldött sorszámot. Kö- 
vessük az ábrán! 

Végül , A" állomás veszi a , B" állomástól érkező TCP szeg- 
menst, és eltárolja a kapcsolatstruktúrájában a ,,B"-től vett y 
sorszámot. Létrehoz egy harmadik TCP szegmenst, a nyugta 
mezőbe beírja az y § 1 értéket, és beállítja az ACK kódbit ér- 
tékét. Az így elkészített szegmenst elküldi ,,B"-nek, aki veszi 
azt. Ezzel a kapcsolat mindkét irányban felépült, a résztvevő 
állomások mindkét irányú adatfolyamra vonatkozólag egyeztet- 
ték a sorszámokat, és a nyugtázás is megtörtént. Kezdődhet az 
adatforgalom. 

Ezt a módszert háromutas kézfogásnak (three way hand- 


shake) nevezzük. 


3.2.3. A TCP adatforgalom 
A megbízható átvitel 


Az IP nem megbízható átvitelére építve a TCP megbízható át- 
vitelt nyújt mindkét irányban. Ehhez mindkét irányban sor- 
számozza az adatfolyam oktettjeit, valamint ellenőrző összeget 
használ. 

Vegyük észre, hogy a TCP az egész szegmensre számítja 
az ellenőrző összeget, az IP pedig csak a fejrészre. így egy IP 
datagramba ágyazott TCP szegmens esetén az ellenőrző össze- 
gek (két részletben) hiánytalanul és átfedés nélkül fedik le a 
datagramot. Az is logikus, hogy melyik protokoll mely részre 


BEzzel tulajdonképpen azt állítja, hogy , A"-tól az adatokat x sorszám- 
mal bezárólag vette, x Tt 1-től várja. 
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számítja az ellenőrző összeget, hiszen az IP feladata a célba jut- 
tatás (,ha sikerül"), így az IP a fejrészt védi, a TCP feladata 
pedig a megbízhatóság biztosítása. (A mai hordozó hálózataink 
maguk is tartalmaznak hibavédelmet, de amikor a TCP/IP pro- 
tokollcsalád létrejött, még sokkal kevésbé voltak megbízhatóak 
a hordozó hálózatok.) 

Amikor megérkezik egy szegmens, a TCP protocol stack ki- 
számítja a szegmens ellenőrző összegét, és összeveti a benne 
szereplővel. Ha nem egyezik, akkor nem használja fel a benne 
szereplő adatokat. Ha az ellenőrző összeg helyes, akkor még 
meg kell vizsgálnia a sorszámot (seguence number), hogy va- 
jon egyezik-e azzal, amit várt. Ha a vártnál kisebb a sorszám, 
akkor feltehetően valami , kóbor" szegmensről van szó (például 
korábban nem érkezett meg időben, újra kérték és most meg- 
jött, vagy esetleg a hordozó hálózat hibájából egy adategység 
megkettőződött), amit nem fogad el. Ha a sorszám a vártnál 
nagyobb, akkor sem fogadja el." Tehát csak akkor fogadja el, 
ha a sorszám pontosan egyezik a várt értékkel. Ekkor előbb vagy 
utóbb nyugtát küld a megfelelő értékkel. A megfelelő érték ki- 
számítása nagyon egyszerű: ha x a sorszám és z oktett érkezett, 
akkor a nyugta értéke: x t z. De mikor is kell a nyugtát elkül- 
deni? A hálózat hatékony kihasználása érdekében nem azonnal. 
Amennyiben van mit küldeni az ellenirányú adatfolyamban, ak- 
kor a nyugtát mintegy , ráültetik" arra az adatfolyamra, vagyis 
a másik irányú adatfolyam TCP szegmensének a nyugta mező- 
jét használják fel. Ezt angolul úgy hívják, hogy piggy backing, 
magyarul ráültetett nyugta a neve. — Természetesen abban az 
esetben, ha egy meghatározott ideig nincs küldeni való az el- 
lenirányú adatfolyamban, akkor elküldünk egy TCP szegmenst 
kizárólag a nyugtázás céljából, hiszen a küldő félnek adott (a 
kapcsolat során megfelelő algoritmussal dinamikusan változta- 


Természetesen tárolhatná is abban a reményben, hogy később hátha 
jó lesz, de ezt nem teszi. 
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tott) idő (timeout) eltelte után újra kell küldenie az adatot, ha 
addig nem kapott nyugtát. 


A forgalomszabályozás 


Egyáltalán miért van szükség forgalomszabályozásra (flow cont- 
rol? Ennek megvilágítására tekintsük a következő szituációt. 
Egy , A" állomás (mint forrás) nagy mennyiségű adatot szeretne 
küldeni egy tőle távoli , B" állomásnak (mint célnak). A kom- 
munikáció sebessége függ mindkét állomás és a közöttük levő 
hálózat sebességétől. Most koncentráljunk csak a két gépre 
(a hálózati forlódás kezelése (congestion control) meghaladja 
e jegyzet kereteit). Amennyiben ,A" minden újabb adategység 
küldése előtt megvárná az előzőre adott nyugtát, az nagymér- 
tékben lassíthatná a kommunikációt. Nézzünk erre egy szám- 
példát: legyen ,A" és , B" távolsága 200 km, az őket összekötő 
üvegszál törésmutatója n — 1,5, a fénysebesség 300000 km/s 
(vagyis az üvegben 200km/ms), az átviteli sebesség 100 Mbit/s. 
Ha egyszerre 1000 bájt hasznos adatot küldünk, és a beágyazás 
során (bőkezűen számítva) még 100 bájt adódik hozzá, akkor 
a 8800 bit leadásához 88 us szükséges. Az oda-vissza út ideje 
csak a terjedési időt számítva is 2ms. Ez azt jelenti, hogy hiába 
lenne szabad az átviteli csatorna, még az idő (és így a csatorna- 
kapacitás) 1/20 részét sem tudjuk kihasználni! És ennél jóval 
nagyobb távolságok és átviteli sebességek is léteznek, ahol az 
arány sokkal rosszabb! Tehát egy állomás nem várhat az elkül- 
dött adategységének a nyugtájára, mielőtt újabbat elküldené. 
Akkor tehát nem fog várni. így azonban egy másik probléma 
merül fel: amennyiben , A" lényegesen gyorsabban küldi az ada- 
tokat (és a hálózat képes átvinni), mint ahogyan , B" képes azt 
feldolgozni, előbb-utóbb megtelnek ,,B" pufferei és az adatok el- 
vesznek. Ekkor a , B"-nél elvesző forgalom a hálózat kapacitását 
fölöslegesen használja. Márpedig léteznek erősen különböző se- 
bességű számítógépeink, tehát a probléma valós. Szükség van 
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tehát egy megoldásra! Ha ,, B" jelezni tudná, hogy vette ugyan 
A" adását, de egy ideig többet nem tud fogadni, az még nem 
jelentene megoldást, hiszen mire a jelzés visszaér ,A"-hoz, arra 
sok adat elindul feleslegesen. Jobb megoldás kell! 

A TCP forgalomszabályozásra a csúszó ablak (sliding win- 
dow) módszert használja. Az ablak értéke egy hitelkeretnek 
tekinthető, azt fejezi ki, hogy egy állomás ennyi adat elküldését 
engedélyezi a másik fél számára úgy, hogy a másik fél még nem 
kapott nyugtát róla. 

A kapcsolat felépülése után az állomások megegyeznek a 
kezdő ablakméretben is, amit később (látni fogjuk milyen mó- 
don és feltétellel) meg is változtathatnak. A módszer műkö- 
désének megértése érdekében nézzünk meg egy számpéldát kis 
számokkal! 


window size — 7. 


he-ENSSEEe[VvVVVVULIAKAI 
Í T 


] T 


ack. no. 


3.11. ábra. A csúszóablak működése 


A 3.11. ábrán az ablak bal széle az utolsó nyugta értékétől 
kezdődik (ez 3, ami azt jelenti, hogy 2-ig nyugtázva, a 3 követ- 
kezik) az ablak mérete pedig 7. Ez a küldő számára azt jelenti, 
hogy a 3-tól 9-ig terjedő sorszámú, összesen 7 darab oktett az, 
amit anélkül elküldhet, hogy nyugtát kapna. Például elküldi 
a 3-6 sorszámú oktetteket. Ekkor nem kell nyugtára várnia, 
hanem küldheti a 7-9 sorszámúakat is. Hogyan csökkentheti a 
fogadó fél az ablakméretet? Esetünkben a 3-6 sorszámú oktet- 
tek vétele után nyugtázza őket (nyugta értéke: 7) és az ablak- 
méretnek legalább 3-nak kell lennie! Ugyanis ha csak 2 lenne, 
akkor a 9-es ezután nem lenne küldhető, pedig korábban az volt. 
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Legyen most az ablakméret 5, ekkor a 7-II sorszámú oktettek 
küldhetők. Az ablak tehát a folyamat során csúszik előre, ezért 
hívják csúszó ablaknak. 

A bevezető számpélda után felmerül a kérdés, hogy vajon a 
TCP-ben használható legnagyobb ablakméret elég nagy-e? A 
16 bites mező 64kB-os" ablakméretet tesz lehetővé, ami 512kbit 
Ennek az átvitele (a fejrészeket elhanyagolva) a példában em- 
lített IDOMbit/s-os hálózaton 5,12ms-ig tart, ami nagyobb a 
2ms-nál, viszont ugyanabban a nagyságrendben van. Márpe- 
dig léteznek gigabites hálózatok, és a 2000 km sem tekinthető a 
valóságtól elrugaszkodottnak. Erre bizony azt kell mondanunk, 
hogy a jelenlegi TCP-vel ebben az esetben nem tudjuk egyet- 
len kapcsolattal kihasználni a hálózat kapacitását. Ez a min- 
dennapi élet szempontjából azért nem okoz súlyos problémát, 
mert az ilyen nagy távolságú és sebességű hálózatok tipikusan 
gerinchálózatok, amit nem egy felhasználó forgalmával kell ki- 
töltenünk. Azt azonban látnunk kell, hogy a csúcstechnológiát 
illetően a jelenleg használt TCP tartalékai kimerültek. 


3.2.4. A TCP kapcsolat lebontása 


A TCP kapcsolat lebontását a 3.12. ábra mutatja be. Ha az , A" 
állomásnak nincs több küldeni valója, a FIN kódbit beállításá- 
val jelzi a , B" állomás számára, hogy kéri a kapcsolat bontását. 
A , B" állomás a beállított FIN bit alapján értesíti az alkalma- 
zást, hogy , A" a kapcsolat bontását kérte, valamint nyugtázza 
az , A"-tól származó sorszámig az adatok vételét. Amikor a ,, B" 
állomáson futó alkalmazás is úgy dönt, hogy lezárja a kapcsola- 
tot, beállítja a FIN bitet az , A" felé küldött TCP szegmensben. 
Az "A" állomás ezt veszi, nyugtát küld, és bontja a kapcsolatot. 
A nyugta megérkezésekor a ,, B" is bontja a kapcsolatot. Ezt 


a megoldást nevezzük négy utas kézfogásnak (four way hand- 


"Egészen pontosan ennél egy bájttal kisebbet, de most ez nem számít. 
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shake). 
A B 
küld FIN, seg-x 
veszi 
küld 
veszi értesíti az alkalmazást 
az alkalmazás lezárja 
a kapcsolatot 
FIN, segzy küld 
veszi 
küld ACK, ack-y--1 


veszi 





idő ] 


3.12. ábra. TCP kapcsolat bontása 


3.3. User Datagram Protocol 


A User Datagram Protocolt az RFC 768-ban definiálták. 
Vannak olyan esetek, amikor nincs szükségünk megbízható 
összeköttetésre, de az alkalmazások közötti kommunikációban 
akkor is szükség van a portokra az alkalmazások azonosításához. 
A User Datagram Protocol (UDP) kapcsolatmentes szállí- 
tási protokoll: datagramok küldését teszi lehetővé a felhaszná- 
lók számára összeköttetés létesítése nélkül. Egy olyan kliens- 
szerver alkalmazás (például DNS névfeloldás, lásd: 5.1.2) szá- 
mára, amely egyetlen kérésre egyetlen választ küld, sokkal elő- 
nyösebb az UDP használata, mint az, hogy TCP kapcsolat fel- 
építésével és lebontásával töltse az időt. Ezen kívül a valós idejű 
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forgalom számára is alkalmatlan a TCP az újraküldési mecha- 
nizmusa miatt. 

Az UDP adategységét user datagramnak hívják, felépítése 
a 3.13. ábrán látható. 


0 16 91 


SOURCE PORT I DESTINATION PORT I 


, TRM SRESE SES e e zÜn ésaz 





LENGTH I CHECKSUM 


DATA 














3.13. ábra. UDP adategységének felépítése 


A user datagram az alábbi mezőket tartalmazza: 


Source Port forrás port 
A portszám azon a gépen, ahonnan a szegmenst küldték. 


Destination Port cél port 
A portszám azon a gépen, ahova a szegmenst küldték. 


Length hossz 
A user datagram teljes méretét adja meg. 


Checksum ellenőrző összeg 
A kiszámításához egy pseudo headert tesznek az UDP 
adategység elé, ami többek között a forrás és cél IP cí- 
meket is tartalmazza", az adategység végén pedig esetleg 
egy 0 értékű oktettel kiegészítik, ha anélkül páratlan ok- 
tettből állna (mert 16 biten történik az ellenőrző összeg 
számítás). 


"így a hibavédelem a portszámon kívül az IP címre is kiterjed. 
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data adatok 
Itt található beágyazva az UDP fölötti protokoll adategy- 


sége. 


Amint említettük, az UDP nem nyújt megbízható átvitelt. 
Amit nyújt, az egyrészt a végpontok azonosítása a portok segít- 
ségével és erre építve multiplexálás/demultiplexálás, másrészt a 
fent említett hibavédelem, amely az UDP adategységen túl az 
IP címekre is kiterjed. 


3.4. Internet Control Message Protocol 


Az Internet Control Message Protocolt az RFC 792-ben defini- 
álták. 

Bár az ICMP az IP rétegre építve szállítja a IP szolgálati 
közleményeit, mégsem tekinthető egy magasabb szintű (a TCP- 
vel és az UDP-vel egy szinten levő, azaz szállítási) protokollnak. 
Éppen a funkciója miatt kötelező része minden IP implementá- 
ciónak. Üzenetei a tanult módon ágyazódnak be: 3.14. ábra. 


éz ő 
w ICMP fej ICMP adatmező 


IP fej ] Datagram adatmező 


Keret fej Keret adatmező 


L szd 





3.14. ábra. Az ICMP adategységének beágyazása. 


A hálózat felhasználói számára az ICMP üzenetek általában 
észrevétlenek, a felhasználó csupán egy jól működő hálózatot 
lát. Van azonban néhány hálózat-karbantartással kapcsolatos 
feladat, amikor a felhasználók is igénybe vehetik az ICMP szol- 
gáltatásait, ezekkel 3.4.3-ban fogunk találkozni, de előbb még 
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megismerjük az ICMP üzenetek formátumát és néhány fonto- 
sabb ICMP üzenetet. 


3.4.1. ICMP üzenetformátum 


Az ICMP üzenetek formátuma egyedi. Ami közös bennük, az 
az ICMP fejrész első 32 bitjén található 3 adatmező. A to- 
vábbi rész kiosztása függ az üzenet típusától. Példaként nézzük 
meg egy tipikus hibaüzenetnek számító ICMP üzenet felépítését 
a 3.15. ábrán! 


[9] 8 16 31 





TYPE CODE CHECKSUM 





UNUSED (0) 





IP HEADER 4 first 64 bit data 











3.15. ábra. A Destination Unreachable ICMP üzenet felépítése 


Az általános, minden ICMP üzenetre jellemző mezők: 


Type típus 
Ez a 8 bites szám adja meg, hogy melyik ICMP üzenetről 
van szó. 

Code kód 


Ennek a 8 bites számnak az értelmezése az ICMP üzenet 
típusától függ. Gyakran az adott típusú üzenet valamely 
altípusát jelenti, de az is lehet, hogy érdemben nem hasz- 
náljuk, ekkor az értéke 0. 


Checksum ellenőrző összeg 
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Ugyanolyan algoritmussal képzett 16 bites ellenőrző ösz- 
szeg, mint az IP-nél. 


4.2 


A további mezők tehát üzenettípusonként eltérőek. Több 
esetben is előfordul kihasználatlan mező, ezt a forrásnak csupa 
0 értékű bitekkel kell feltöltenie, a címzettnek pedig figyelmen 
kívül kell hagynia az értékét. Amennyiben hibaüzenetről van 
szó, az ICMP üzenet tartalmazza még a hibaüzenetet kiváltó 
IP datagram fejrészét és az adatrész első 64 bitjét. Vegyük 
észre, hogy az IP réteg nem tudja, hogy fölötte mi utazik, de 
akár TCP, akár UDP, ez a 64 bit tartalmazza a hiba kezelésé- 
hez szükséges információt. Miért csak TCP-t és UDP-t emlí- 
tettünk? Azért, mert ICMP üzenettel kapcsolatos hiba követ- 
keztében nem keletkezhet újabb hibaüzenet! Ez fontos védelem 
a hibaüzenetek öngerjesztő elszaporodása ellen, viszont ez azt 
is maga után vonja, hogy ICMP üzenetek nyom nélkül elvesz- 
hetnek. Ezt természetesen tolerálni tudjuk, hiszen az IP réteg 
amúgy sem megbízható! 


3.4.2. Fontosabb ICMP üzenetek 


Ismerjük meg a fontosabb ICMP üzeneteket! Az egyes üzene- 
teknél zárójelben megadjuk azok típusszámát is. A felsorolás- 
ban az RFC 792-beli sorrendet követjük. 


Destination Unreachable (3) cél nem elérhető 
Ennek több oka lehet, amiket a Code mező tartalma kü- 
lönböztet meg: 


0 — net unreachable a célhálózat nem elérhető 


1 — hőst unreachable a célgép nem elérhető 


2 — protocol unreachable a kívánt (IP fölötti) proto- 
koll nem elérhető 


3 — port unreachable a kért port nem elérhető 
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4 — fragmentation needed and DF set a datagram 
tördelésére lenne szükség, de a DF (do not fragment) 
bit be van állítva 


5 — source route failed a forrás általi útvonalválasz- 


tás" sikertelen 


Time Exceeded (11) időtúllépés 

Ha egy datagram TTL-je lejár (0-ra csökken), akkor az az 
útvonalválasztó, ahol éppen tartózkodik, köteles eldobni 
a datagramot. Ilyenkor ezzel az üzenettel jelezheti a for- 
rás számára, hogy eldobta. Tördelt datagram esetén a 
cél állomás összerakáskor eldobja a töredéke(ke)t, ha a 
TTL lejár, ilyenkor ugyancsak ezzel az üzenettel jelezheti 
a forrás számára a hibát. 


Paraméter Problem (12) érvénytelen fejrészmező 
Ha egy útvonalválasztó vagy egy számítógép nem tudja ér- 
telmezni egy datagram fejrészének valamely mezőjét (pél- 
dául Type of Service vagy valamilyen opció), és ennek 
következtében eldobja a datagramot, ilyen üzenettel je- 
lezheti azt a forrás számára. Ez az ICMP üzenet az első 
32 bitje után tartalmaz egy 8 bites pointert. Ha a Code 
mező értéke 0, akkor ez a pointer az eredeti datagram- 
nak arra az oktettjére mutat, amely a problémát okozta. 
Természetesen az eredeti datagram fejrésze és az első 64 
adatbitje is része az üzenetnek (32 bites határra igazítot- 


tan elhelyezve). 


Source Ouench (4) forráslefojtás" 
Ha egy útvonalválasztó nem tudja kezelni a túlságosan sok 
érkező datagramot (nem fér el a pufferében) és eldobja a 
datagramot vagy egy állomás nem győzi feldolgozni az 


"Erről 4.1.2-ben fogunk tanulni. 
" Ezek az üzenetek is tovább növel(het)ik egy hálózat túlterheltségét. 
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érkező datagramokat, ezzel az üzenettel jelezheti a forrás 
számára, hogy csökkentse a datagramok időegységenkénti 
számát. (Ezt a forrás köteles figyelembe venni és a Source 
Ouench üzenetek megszűntéig csökkentenie kell az adás 
sebességét. Utána fokozatosan újra növelheti, amíg újabb 
ilyen üzenetet nem kap.) 


Redirect (5) átirányítás 

Egy router megadhat egy állomásnak egy rövidebb utat 
a datagramban szereplő cél felé, de ettől még továbbítja 
az eredeti datagramot. (A háttérben az van, hogy a rou- 
terekről feltételezzük, hogy pontosan tudják, merre vezet 
a rövidebb útvonal, míg az állomások nem, de így meg- 
tanulhatják.) A kód mező fejezi ki, hogy pontosan mit is 
értünk cél alatt: 


0 — Network hálózat 

1 — Host állomás 

2 — Type of Service and Network szolgáltatástípus 
és hálózat 

3 — Type of Service and Host szolgáltatástípus és 
állomás 


Echo (8) visszhang kérés 
A forrás arra kéri a címzettet, hogy küldje vissza az üze- 
netet. A minden ICMP üzenetben azonos funkciójú első 
32 bit után ez az üzenet tartalmaz egy 16 bites azonosítót, 
és egy 16 bites sorszámot. Ez utóbbi az egymást követő 
üzenetekben egyesével nő. 


Echo Reply (0) visszhang válasz 
Az Echo üzenet címzettje ezzel az üzenettel válaszol. A 
válasz mezői általában megegyeznek a kérés mezőivel, de 
természetesen a típus mező nem, és az ellenőrző összeget 
is újra ki kell számítani. 
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Timestamp (17) időbélyeg kérés 
Az Echo üzenetet további 3 mezővel bővíti: 


Originate Timestamp küldési időbélyeg 
Receive Timestamp vételi időbélyeg 


Transmit Timestamp visszaküldési időbélyeg 


Az időbélyegek az UTC szerint éjfél óta eltelt időt tartal- 
mazzák ms-ban mérve. 


Timestamp Reply (18) időbélyeg válasz 
Válasz a Timestamp üzenetre. A válaszoló a mezőket az 
Echo Replyhoz hasonlóan másolja, illetve értelem szerint 
kitölti. 


3.4.3. Felhasználók számára is elérhető ICM P üze- 
netek 


Van két olyan hálózati tesztelésre szolgáló parancs (segédprog- 
ram), ami a legtöbb operációs rendszeren megtalálható (esetleg 
más néven). 


A ping parancs 


A ping parancs egy vagy több visszhang kérés ICMP üzenetet 
küld a felhasználó által megjelölt másik gépre. A címzett pedig 
visszhang válasz ICMP üzenetet küld annak a gépnek, ahonnan 
a kérés érkezett. A felhasználó ilyen módon tesztelheti, hogy 
egy másik gép elérhető-e a hálózaton keresztül. 

A ping parancs célszerűen kiírja a visszaérkező üzenetből a 
TTL értékét, így azt is megtudhatjuk, hogy milyen távol van a 
vizsgált gép (útvonalválasztók számában mérve). 

A ping parancs ezenkívül mérni szokta a visszhang kérés 
küldése és a vele azonos sorszámú visszhang válasz megérkezése 
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között eltelt időt, így megtudhatjuk a teljes oda-vissza út idejét 
(RTT, round-trip time). 


A traceroute parancs 


A traceroute parancs egy távoli géphez vezető útvonal során 
érintett útvonalválasztók válaszidejét" deríti ki. 

Ehhez többféle trükkös módszert is használhat, például egy 
elterjedt megoldást, hogy a vizsgált eszköz (router) 33434-es 
UDP portjára" küld egy UDP csomagot. A beállított TTL-t 
1-ről növeli. Amíg túl kicsi, addig time exceeded üzenetet kap 
vissza valamelyik közbenső routertől, amikor pedig már elég 
nagy, akkor port unreachable üzenet érkezik (feltéve, hogy a 
33434-es porton nem figyel alkalmazás, ha mégis, akkor a fel- 
használó választhat más portot). Alternatívaként a felhasználó 
azt is megadhatja, hogy UDP datagram helyett echo ICMP 
üzenetet küldjön. 


3.5. — Kiegészítő protokollok 


Ahhoz, hogy IP protokollt használhassunk valamilyen hálózati 
megvalósítás (például Ethernet) felett, szükség van még arra, 
hogy az általuk használt címek között kapcsolatot teremtsünk. 


3.5.1. — Address Resolution Protocol 


Az IP négy oktett méretű címeket használ az állomások azo- 
nosítására, míg a hálózati megvalósításoknak is megvan a saját 


BAz időben benne van a teljes oda-vissza út ideje (RTT - round-trip 
time), valamint a válasz előállításának az ideje, ami erősen függ a router 
terheltségétől. 

"Egy várhatóan nem használt célport, szükség esetén lehet változtatni, 
BSD-ben lehet TCP-t is használni. 
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címzési rendszere. Például az Ethernet 6 bájtos címeket hasz- 
nál. Az IP négy oktettjéről a 6 bájtos MAC címre való lekép- 
zést hívjuk címfeloldásnak, amit az Address Resolution Protocol 
(ARP) segítségével valósítunk meg. Ennek a működéséhez fon- 
tos körülmény, hogy mindig csak olyan állomások IP címéhez 
kell kiderítenünk a hozzájuk tartozó MAC címet, ami velünk 
azonos fizikai hálózaton van. 

Hogyan működik az ARP? Amikor egy számítógépnek vagy 
útvonalválasztónak szüksége van egy vele szomszédos, ismert 
IP című másik számítógép vagy útvonalválasztó MAC címére, 
akkor küld egy broadcast üzenetet, amiben megkérdezi, hogy 
kihez tartozik az adott ismert IP cím. A broadcast üzenetet 
mindenki veszi az adott hálózaton, és az IP cím gazdája vála- 
szol: megmondja a saját MAC címét. 

Az algoritmus hatékonysága cache-eléssel fokozható: 


. amikor egy állomás ARP kérést küld, megadja a saját IP 
címét is, így a többiek eltárolhatják az IP cím - MAC cím 
párost 


. a kapott választ is eltárolhatják a többiek is 


. amikor egy állomást bekapcsolnak, akkor az állomás ARP 
kérést küld a saját IP címére, és utána válaszol is, ezt is 
tárolhatják a többiek 


Ha két gép azonos IP címet szeretne használni, az hiba. Ez 
akkor derül ki, ha egy gép induláskor küld egy ARP kérést a 
saját IP címére, és más válaszol. Ilyenkor szabály, hogy az 
újonnan indulónak illik visszalépnie. Ezt nem mindenki tartja 
be. 


3.5.2. — Reverse Address Resolution Protocol 


Előfordulhat olyan szituáció is, amikor éppen az ARP fordított- 
jára van szükség. Például egy merevlemez nélküli munkaállomás 
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esetén a hálózati kártya egyedi MAC címe alapján szeretnénk 
megkapni a hozzá tartozó IP címet. Erre is lehetőségünk van, de 
ehhez szükségünk van egy RARP szerverre. Ilyenkor a RARP 
kérdésre a RARP szerver válaszol. Miért jó ez? Mert elegendő 
azonos boot EPROM-ot tenni minden gépbe, amelyek a szük- 
ségszerűen különböző MAC cím alapján a RARP segítségével 
ki tudják deríteni a saját IP címüket, amivel aztán képesek 
kommunikálni. Az operációs rendszert aztán hálózaton keresz- 
tül fogják betölteni. Ma már ritkán használják erre a célra a 
RARP-ot, helyette van más protokoll, a DHCP, ami lényegesen 
többre is képes. 


3.6. . Az Internet Protocol 6-os verziója 


Bár a , B" osztályú IP címek elfogyását követően a , C" osztályú 
címek CIDR segítségével való összevonása, valamint az ,A" és 
, B" osztályú címek visszaadása, illetve kisebb tartományra való 
cseréje még átmeneti megoldásként alkalmas volt, de nyilvánva- 
lóvá vált, hogy a címteret erősen ki kell bővíteni." 


A téma mélyebb megismerésére az irodalomjegyzékben meg- 
adott könyv [9] viszonylag jól használható, bár mivel 1998. de- 
cemberénél (az IPv6-ot definiáló RFC 2460 dátumánál) előbb 
írták, így előfordulhatnak eltérések. Az alábbiak írásához fel- 
használtuk, de sajnos részben elavult [17], az IPv6 fejrész hibá- 
san szerepel benne. (Tanulság: egy forrást érdemes összevetni 
a vonatkozó RFC-vel!) Egy magyar nyelvű összefoglaló: [1]. 


"Különféle trükkökkel, mint a címfordítás (NAT) még mindig működik 
az IPv4 rendszer, így még mindig nem kényszer az IPv6-ra való áttérés. 


106 


3. FEJEZET. INTERNET PROTOKOLLKÉSZLET 


3.6.1. — Az IPv6 protokoll kialakításának főbb szem- 


pontjai 


Sokan és sokféle igénnyel léptek fel, hogy milyen legyen az új 
Internet Protocol", ezeknek az érdeklődők magyar nyelven is 
utána olvashatnak [17] megfelelő fejezetében. A következőket 
tartjuk igazán fontosnak és előremutatónak: 


Legyen elegendő IP cím - még a címtartomány nem ha- 
tékony kihasználása esetén is. Felkészülni az előre nem 
látható igények kielégítésére is. 


Csökkenteni a forgalomirányító táblázatok méretét. A je- 
lenlegi kétszintű címzés (hálózati prefix t gépcím) helyett 
valami jobbra lenne szükség, mivel már nagyon sok háló- 
zat létezik. 


veg 


A protokoll egyszerűsítése a csomagok gyorsabb feldolgo- 
zása érdekében. (Mivel a hálózatok sebessége körülbelül 
két nagyságrenddel" megnőtt, a routereknek egyre keve- 
sebb idő alatt kell dönteniük az útvonalak felől.) 


Biztonság javítása (titkosság, hitelesség). Ez szinte telje- 
sen hiányzott az IPv4 tervezési szempontjai közül. 


Type of Service - szolgálat típusának jobb támogatása. 
Az IPv4-es DTR biteket és a prioritást nem is szokták 
figyelembe venni a routerek, most az alkamazások igénye 
miatt ennél kifinomultabb megoldásra lenne szükség. 


A többesküldés (multicast) jobb támogatása. Például au- 
dió és videó műsorszórás gazdaságos megvalósításához. 


Mobilitás támogatása. Szintén új felhasználó igény. 


"Nevezték úgy is, hogy next generation IP vagy röviden: ngIP. 
"például 10 Mbit/s-ról 1 Gbit/s-ra 
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, A protokoll fejleszthető legyen. Ha később előre nem lát- 
ható változtatásra lesz szükség, az a protokoll lecserélése 


nélkül megvalósítható legyen. 


e IPv4 és IPv6 együttélése lehetséges legyen. Az átállásnak 
fokozatosnak kell lennie. Először kisebb szigetek alakul- 
hatnak, majd ezek olvadhatnak össze. 


Ezen szempontok alapján - kellően sok megfontolás és vita 
után - az új protokoll az RFC 2460-ban leírt 6-os verzió lett. 


3.6.2. — Az IPv6 datagram felépítése 


Az IPv6 adategységének felépítése a 3.16. ábrán látható." 


12 16 24 31 


o 4 


VERSION TRAFFIC CLASS FLOW LABEL 
PAYLOAD LENGTH NEXT HEADER HOP LIMIT 





3.16. ábra. IPv6 datagram felépítése 


Az IPv6 datagram mezőinek jelentése: 


4 Egyszerű, tömör leírás található róla például: [29] 
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Version (4bit) verziószám 
Ertéke természetesen: 6. 


Traffic Class (8 bit) forgalmi osztály 
Az IPv4 Type of Service mező utódja. Az RFC 2474 sze- 
rinti Differentiated Services megoldást használjuk. 


Flow Label (20 bit) folyam címke 
Virtuális áramkör jellegű működést tesz lehetővé. Kísérle- 
tinek (experimentál) tekinthető, az értelmezése változhat. 


Payload Length (16bit) adatmező hossza 
Mivel 16 bit hosszú, így értéke legfeljebb 65535 lehet. Az 
IPv4-gyel ellentétben itt a fejrész 40 oktettje nem számít 
bele, ezt fejezi ki a neve is: , hasznos teher hossza". 


Next Header (8bit) következő fejrész 

Megmutatja, hogy mit hordoz az IP címek utáni rész. Ez 
a mező egyrészt tartalmazhatja az IPv6 fölötti protokoll 
típusának megadását (ilyen értelemben az IPv4 Protocol 
mezőjének utódja), másrészt ezzel ki lehet terjeszteni a 
fejrészt, ahova további mezők kerülhetnek (ilyen értelem- 
ben az IPv4 Options mezőjét is helyettesíti). Ez utóbbi 
esetben a főfejrész (a címekkel befejeződő 40 oktett) után 
jön egy következő fejrész. 


Hop Limit (8 bit) átugrás korlát 
Funkciója megfelel az IPv4 Time To Live mezőjének, de 
az elnevezése jobban kifejezi a funkcióját, és a mértékegy- 
sége sem másodperc (hanem darab). 


Source Address (128 bit) forrás IPv6-os címe 
Az IPv6 címekkel külön foglalkozunk. 


Destination Address (128 bit) cél IPv6-os címe 
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Megjegyzések 


1. Elvileg egy router a verziószámból tudná, hogy az utána 
következő mezőket nem IPv4, hanem IPv6 mezőknek kell 
tekinteni. Gyakorlatilag nem így történik, mert már a 


hordozóhálózatban az IPv4-től eltérő protokoll azonosítót 
használnak az IPv6-ra. 


2. A virtuális áramkör egy olyan átviteli mód, amelynek so- 
rán minden adategység azonos útvonalon halad és azonos 
elbánásban részesül. (Mintha csak egy külön számukra 
készített áramkörkapcsolt csatornán haladnának. így eb- 
ben az esetben nem fordulhat elő például az adategységek 
sorrendjének felcserélődése.) Virtuális áramkörrel történő 
kommunikáció során az alábbi lépések játszódnak le: 


útvonalfelépítés, ennek során minden csomópontban 
információ tárolása a kapcsolatról 


(a 


ke 


(b) minden csomag a felépített útvonalon halad 
(c 


útvonal bontása, ennek során a csomópontokban tör- 
lődik a kapcsolatról szóló információ 


Ms 


(Esetünkben a két állomás IP címe és a FLOW LABEL 
egyértelműen azonosítja a kommunikációt.) 


3. Az adatmező hosszát alapesetben a 16 bites érték való- 
ban erősen korlátozza, de lehetőségünk van úgynevezett 
jumbogramm kialakítására is. Ez 64kB-nál jóval nagyobb 
csomag is lehet, így a routereknek nem kell annyiszor a 
fejrészt feldolgozniuk, tehát gyorsul a rendszer. 
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3.6.3. IPv4 - IPv6 fejrészeinek összehasonlítása 


Mindkettő verziószámmal kezdődik. 


Utána az IPv4-ben a fejrész hossza következik, amiből tud- 
hatjuk, hogy hol kezdődik az adatrész. Az IPv6-nál nincs fejrész 
hossz mező, mert mindig azonos a fő fejrész, ehhez jöhet hozzá 
a Next Header mezővel való kiterjesztés. 


sb 


Már az IPv4 7ype of Service mezőjét is a Differentiated Ser- 
vices célra használják (elvileg), így az IPv6 Traffic Class mezője 
ennek szerves utódja. Ezen kívül a Next Header mezőben van 
lehetőség a kapcsolatra vonatkozólag elrejteni szempontokat, és 


b 


később a Flow Label mező segítségével használni. 


A tördelést teljesen megszüntették, hogy ne terhelje a route- 
reket. Helyette - szükség esetén - a teljes útvonalon előre meg 
kell határozni a maximális használható adategység méretet és 
azt kell használni. (így eltűntek az Identification és a Fragment 
Offset mezők valamint a DF és MF jelzőbitek.) 


A Time To Live helyett - helyesebb névvel - Hop Limitet 
használunk. 


Az IPv6 fejrészre nem képeznek ellenőrző összeget. Egyrészt 
a hordozó hálózatok megbízhatósága ezt már nem indokolja, 
másrészt meg ha - nagyon ritkán - egy-egy datagramot mégis 
hibásan (ezért potyára) továbbítunk a cél felé (ahol majd egy 
felsőbb rétegbeli protokoll észreveszi a hibát és eldobja), az sem 
jelent akkora kárt, mintha az összes routerrel kiszámoltatnánk 
az ellenőrző összeget. 


Az opciókat pedig sikerült elrejteni a Next Header megol- 
dással. 
A protokoll tervezői valóban elérték azt a célkitűzést, hogy 


a fejrész egyszerűsödjön. A jobb megoldások mögött ott áll az 
IPv4 használata során szerzett nagy mennyiségű tapasztalat. 
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3.6.4. IPv6ó címek 
IPvó címek írása 


Az IPv6-os cím 128 bitből áll, 16 bites csoportonként 4 hexade- 
cimális jeggyel írjuk, a csoportokat kettősponttal (,,:") választ- 
juk el egymástól. A csoportok elején a nullák - egy csoportban 
legfeljebb háromszor - mindig elhagyhatók. így amennyiben 
egy 16 bites csoportban 4 nulla áll egymás után, azt mindig 
helyettesíthetjük egy nullával. Ha egymás utáni 16 bites cso- 
portok csak nullákat tartalmaznak, az összes ilyen csoportot 
helyettesíthetjük dupla kettősponttal (,,::"), de ez egy címben 
csak egyszer alkalmazható, hogy a dekódolás egyértelmű legyen. 
Lássunk egy példát: 


A00€ : 0000 : 0000 : 00AE : 0000 : 0000 : 0000 : ABCD 


j 
A00C : 0: 0: AR :0:0:0: ABCD 
b 
A00€ : 0: 0: AE :: ABCD 
Az alábbi formában megtartható az IPv4-es formátum is: 


:: 193.224.130.161 


(Ez olyan IPv6 címet jelent, aminek az utolsó 32 bitjében egy 
IPv4 cím található, a többi bitje pedig 0.) 


IPv6ó címek csoportjai 


Mivel az IPv6 címek 128 bitesek, kellően sok van belőlük. Terve- 
zéskor nem látták előre, hogy milyen szempontok fognak felme- 
rülni a címek struktúrájának kialakításával kapcsolatban. Két 
szempont kellően logikusnak tűnt: 
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44 


. támogassuk a kettőnél több szintű struktúrát 


." hagyjunk szabadságot arra, hogy mi legyen a strukturálási 
szempont 


Természetesen a tervezőknek valamerre el kellett indulniuk, 
így eredetileg definiáltak például olyan címcsoportot, ahol föld- 
rajzi alapon és olyant is, ahol szolgáltatók szerint osztják ki a 
hálózatokat. Akkor úgy tűnt, hogy ez jól szolgálja az aggre- 
gálhatóságot, de aztán felülbírálták és megszüntették. Jelenleg 
inkább a Regional Internet Registryknek [37] osztanak ki na- 
gyobb tartományokat és azok osztják szét saját hatáskörben a 
kérelmezőknek. 

Az IPv4 címek osztályainak jelzéséhez hasonlóan az IPv6- 
ban előtagokat használnak a különböző címcsoportok megkü- 
lönböztetésére. A jelenleg érvényes IPv6 címzési architektúrát 
az RFC 4291 írja le. Most áttekintjük a fontosabb címcsopor- 
tokat. 


0000:/8 Reserved Ebben a tartományban vannak a követke- 
zők: 


::/128 Unspecified Address meghatározatlan cím, ak- 
kor használjuk, amikor egy host inicializálja magát. 

::1/128 Loopback Address A 127.0.0.1 IPv4 loopback 
címhez hasonlóan használt loopback cím. 


::/96 IPv4-Compatible IPv6 Address Eredetileg az 
IPv4 —: IPv6 átmenethez való felhasználásra szán- 
ták, de már más megoldást (lásd következő) találtak 
ki, ezért érvénytelenítették. 


:: FFFF:/96 IPv4á-Mapped IPv6 Address Ebben az 
új megoldásban egy tetszőleges x.y.z.w IPv4 címet a 
:FFFE-x.y.z.w IPv6 címmel reprezentálnak. 

(A korábbi ::x.y.z.w helyett azért kellett másik, mert 
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változott a módszer, amit az IPv4 — " IPv6 átmenet- 
hez szeretnének alkalmazni.) 


FE30::/10 Link-Local IPvó Unicast Addresses Olyan cí- 
mek, amik csak egy adott fizikai linken érvényesek, pél- 
dául egy Ethernet szegmensen. Az ilyen forráscímmel 
rendelkező IPv6 csomagokat a routerek nem továbbítják. 
Olyan esetekben használjuk, amikor például egy IPv6 há- 
lózatban nincs router, vagy neighbour discovery (lásd ké- 
sőbb) esetén. 


FECO::/10 Site-Local IPvó Unicast Addresses Ez a tar- 
tomány ma már nem használt, érvénytelenített. Eredeti- 
leg az egy adott site körzetén belüli címzésre definiálták 
(mint IPv4-nél az RFC 1918 szerinti lokális címeket), de 
a site fogalmának nehéz meghatározhatósága miatt már 
nem használatos, lásd: RFC 3879." 


FFOO::/8 Multicast Addresses Broadcasthoz és multicast- 
hoz használt címek. A cím második bájtja két darab 4 
bites mezőre oszlik. Az elsőben különböző flageket defini- 
áltak aszerint, hogy permanensen kiosztott (well-known) 
vagy tranziens címről van szó, stb. A második mező a 
hatály vagy körzet (scope). Ez az adott cím érvényes- 
ségi tartományát adja meg. Ez lehet - többek között - 
csak adott linken érvényes (link-local), adminisztratív mó- 
don meghatározott (admin-local), adott szervezeten belüli 
(organization-local) és globális. 


A multicast cím további része a csoportazonosító (group 
ID). Ez a címzettek egy alcsoportját határozza meg. Előre 


5 Az RFC azt is leírja, hogy a másik probléma, ami IPv4-nél is előjött, 
az az, hogy a lokális(nak szánt) IP címek esetenként mégis kiszivárognak, 
ilyenkor aztán mindenféle gondot okoznak, ráadásul még azt sem lehet 
megtalálni, hogy honnan jöttek. 
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definiált csoportazonosító például az 1-es és a 2-es. Ezek 
alapján az FFO2::2 cím az adott linken levő összes rou- 
tert címzi meg: a 2-es csoportazonosító az összes router 
(all-routers) cím, az FFO02-ben a 2-es pedig link-local tar- 
tományt ad meg. Az FFO5::2 pedig az összes site-on belüli 
routert címzi meg. 


Az 1-es csoportazonosító az összes csomópont (all-nodes) 
cím. így az FF0O2::1 a linken található összes hostot címzi 
meg, ami nem más, mint a broadcast cím. Vegyük észre, 
hogy az IPv6 ezen a ponton gyökeresen eltér az IPv4-ben 
megszokott broadcast címzéstől! 


FC0OO::/7 Unigue Local Unicast Addresses Az RFC 4193 
definiálja. — Ilyen címek használatával olyan helyeken is 
lehet IPv6-ot használni, ahol nincs hivatalosan kiosztott 
IPv6 prefix, azaz felhasználásuk célja teljesen hasonló az 
RFC 1918-ban meghatározott privát IPv4 címekhez. Nagy 
különbség azonban, hogy az ilyen címeknél a network ID 
meghatározásához egy álvéletlen (pseudo-random) címet 
használunk, amit az RFC-ben megadott módon lehet elő- 
állítani. Több szervezeti egység is generálhat így magának 
címet, és a pseudo-random algoritmusnak köszönhetően 
nagyon kicsi valószínűséggel fognak ezek a címek ütközni. 


Global Unicast Addresses Az IPv6 címtartomány megma- 
radó része globálisan routolható unicast címzésre van fenn- 
tartva. A címek kiosztását az IANA végzi. Jelenleg a 
2000::/3-on belül vannak kiosztva prefixek. Az ilyen cí- 
mek szerkezete a 3.17. ábrán látható. A global routing 
prefix az IANA által kiosztott tartomány". Az alháló- 
zati címtartomány kiosztása hasonló az IPv4-nél megis- 
merthez. Az interface ID a csomópont adott hálózati in- 


"például a 2001:738:2001::/48 a BME tartománya 
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td 4 


terfészének címe. Ez előállítható kézzel is, de lehetőség 
van automatikus konfigurációra is. Ilyenkor az adott in- 
terfész (tipikusan Ethernet) MAC címe alapján állítjuk 
elő az interface ID-t egy egyszerű eljárással (módosított 
EUI64 eljárás). Az eljárás az RFC 4291 ,A" függeléké- 
ben olvasható. Az egyes állomások a hálózati címüket 
is tudják automatikusan konfigurálni az RFC 2462-ben 
meghatározott módon (stateless autoconfiguration). Eb- 
ben az esetben a cím az adott hálózatban levő IPv6 router 
hirdetései és a megfelelő interface EUI64 címe alapján áll 





elő. 
n-bit m-bit 128-n-m-bit 
global routing prefix subnet ID interface [ID 





3.17. ábra. Globális unicast IPv6 címek felépítése 


Az IPv4-ben az IPv4 cím és a MAC cím közti összerendelést 
az ARP protokoll segítségével végzi el egy host. Az IPv6-ban 
ennek az RFC 2461-ben leírt neighhor discovery eljárás felel 
meg. Ez sok más eljárást is tartalmaz. Számunkra jelenleg az 
IPv4-hez képest a legjelentősebb különbség az, hogy itt nem 
külön ARP-szerű protokoll van, hanem az ICMPvő6 segítségével 
oldjuk meg a feladatot. 
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4. fejezet 


Útvonalválasztás 


Adott nagy számú hálózat, amelyeket úgy kell összekötnünk 
egymással, hogy bármely hálózatból bármely hálózatba kül- 
dendő csomagjaink eljussanak a címzetthez. Az útvonalválasz- 
tási . (routing) feladat megoldása hálózati protokolltól függően 
más-más lehet. Mi csak IP routinggal foglalkozunk. Az egyes 
hálózatokat összekötő elemeket útvonalválasztóknak (router) ne- 
vezzük. A routereknek kell eldönteniük, hogy egy adott célcím- 
mel rendelkező IP datagramot melyik irányba továbbítsanak. 
Minek alapján teszik ezt? A táblázat alapú útvonalválasztás 
esetén a routerek olyan táblázatokkal rendelkeznek, amik tar- 
talmazzák az ehhez szükséges információt. A csomagok továb- 
bításakor csupán felhasználják a táblázataikat a döntésekhez. 
Egy másik fontos kérdés az, hogy hogyan töltik fel a táblázata- 
ikat. Vizsgáljuk meg sorban ezeket, és a még közben felmerülő 
problémákat! 


" Szokták még forgalomirányításnak is nevezni. 
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4.1.  Datagramok továbbítása 


4.1.1. — Táblázat alapú útvonalválasztás 
A táblázat alapú útvonalválasztást egy példán mutatjuk be. 


11.0.0.1 R 172.12.0.1 
l 


11.000 


(A) l 


72.12.0.0 


Host IP addr.:11.0.0.23 
11.0.0.2 


R, 
193.225.159.1 


172.12.0.2 


193.224.128.0 


193.225.159.0 
(B) 


R, 
193.225.159.2 193.224.128.1 


Host IP addr.:193.224.128.34 


4.1. ábra. IP hálózat routerekkel 


A 4.1. ábrán négy hálózatot látunk, amelyeket az R,, R,, 
R, routerek (útvonalválasztók) kapcsolnak össze. Minden háló- 
zathoz hozzárendeltünk egy-egy hálózatcímet. A hálózatokban 
számítógépek helyezkednek el, és a saját hálózatukból kapnak 
IP címet. A routerek hálózati interfészei is kapnak IP címet 
azokból a hálózatokból, ahova csatlakoznak. A routereknek 
nem kell tudniuk, hogy például a megjelölt ,A" géptől a szin- 
tén megjelölt , B" gépig mi lesz a datagramok teljes útvonala, 
elég annyit tudniuk, hogy nekik melyik szomszédjuk felé kell 
továbbítaniuk a datagramot, ha az egy adott IP című gépnek 
szól (példánkban ez a , B" gép). A routerek az útvonalválasztási 
táblázataik (routing table) alapján tudják, hogy adott célháló- 
zatba (destination network) merre vezet a következő lépés, azaz 
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melyik (milyen IP című) routernek (next hop address) kell to- 
vábbítaniuk a datagramokat. 

Nagyon fontos, hogy a routing táblázatokban nem az összes 
lehetséges IP cím, csupán a hálózatcímek szerepelnek! Ez nagy- 
ságrendi különbség! A routerek útvonalválasztási táblázatai te- 
hát két oszlopot (destination network address, next hop add- 
ress) és annyi sort tartalmaznak, ahány hálózat van. A 4.1. áb- 
rán látható hálózat routereinek útvonalválasztási táblázatait 
megtaláljuk a 4.1. - 4.3. táblázatokban. 

















destination network address ! next hop address 
11.0.0.0 direct delivery 
172.12.0.0 direct delivery 
193.225.159.0 11.0.0.2 
193.224.128.0 11.0.0.2 














4.1. táblázat. R, routing táblázata 

















destination network address ! next hop address 
11.0.0.0 193.225.159.1 
172.12.0.0 193.225.159.1 
193.225.159.0 direct delivery 
193.224.128.0 direct delivery 














4.2. táblázat. R, routing táblázata 


A tábla alapú útvonalválasztás algoritmusa 


Fontosnak tartjuk hangsúlyozni, hogy ma a routerek nem így 
működnek, az algoritmust csak didaktikai céllal ismertetjük. 
Az útvonalválasztás lépései a következők: 
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destination network address ! next hop address 
11.0.0.0 direct delivery 
172.12.0.0 direct delivery 
193.225.159.0 direct delivery 
193.224.128.0 193.225.159.2 














4.3. táblázat. R, routing táblázata 


e A cél IP címből a router annak osztálya alapján megha- 
tározza a célhálózat címét. 


e Ezután egy ciklust hajt végre a routing táblájának a so- 
raira. (Az első során kezdi, és veszi a következőt, ha szük- 
séges.) 


- A ciklus magjában összehasonlítja a datagram cél 
IP címéhez tartozó célhálózat címet a táblázat adott 
sorában levő célhálózat címmel (destination network 
address). 


x Ha egyezik, akkor a következő ugrás címe (next 
hop address) mező szerint jár el. Amennyiben 
itt egy IP címet talál, akkor az a következő rou- 
ter IP címét jelenti, tehát neki küldi a data- 
gramot. Amennyiben itt azt találja, hogy direct 
delivery, az azt jelenti, hogy a célhálózat közvet- 
lenül kapcsolódik ehhez a routerhez, tehát köz- 
vetlenül kézbesíti a cél IP cím alapján a címzett- 
nek. Ezek után a ciklusból kilép, a továbbítás 
sikeres volt. 

X Ha nem egyezik, akkor a ciklust folytatja a táb- 
lázat következő során. 
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" Ha elfogytak a táblázat sorai, és nem sikerült a data- 
gramot továbbítani, akkor a destination unreachable ICMP 
üzenetet küldi a datagram küldőjének (a forrás IP cím 
alapján). 


Megjegyzés: a táblázat végén nagyon gyakran (például egy 
host, vagy egy olyan router esetén, amely néhány helyi háló- 
zat és az Internet között routol) van egy alapértelmezett átjáró 
(default gateway), amelynek továbbítja a csomagot, ha másnak 
nem tudta. 

Melegen javasoljuk az Olvasó számára, hogy kövesse nyomon 
az ,A" állomás által a , B" állomás számára küldött datagram 
útját úgy, hogy végigjátssza az útvonalválasztást minden rou- 
teren, ahol áthalad. A megoldás során használja a megadott 
routing táblázatokat (4.1. - 4.3. táblázatok), és kövesse a data- 


gram útját a 4.1. ábrán! 


Gyakorlati probléma 


A módszer elméletileg kiváló, a gyakorlatban azonban sajnos 
nem használható. Ugyanis az A, B, C osztályú IP címek kon- 
cepciója azt feltételezte, hogy egy intézménynek egy hálózata 
van. Ezzel szemben egy-egy intézmény hálózata több fizikai há- 
lózatból áll. (Az semmiképpen sem járható út, hogy minden 
intézmény annyi hálózatcímet kapjon, ahány fizikai hálózattal 
rendelkezik, mert nincs annyi hálózatcím!) 

Más megoldásra van tehát szükség. Hamarosan megvizsgá- 
lunk néhány módszert erre, de előbb tegyünk egy kis kitérőt! 


4.1.2. Forrás által végzett útvonalválasztás 


Természetesen akár azt is megtehetjük, hogy a forrásnál előre el- 
döntjük, hogy egy datagramnak milyen úton kell haladnia. Ezt 
úgy hívják, hogy forrás által végzett útvonalválasztás (source 
routing). 
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A módszer nyilvánvalóan nem versenyképes a táblázat alapú 
útvonalválasztással, hiszen jelentős hátránya, hogy az összes 
számítógépnek tudnia kell minden általa használt cél felé a pon- 
tos útvonalat.  Tesztelési célokra azonban használják a mód- 
szert. A datagram opciójaként lehet megadni, hogy forrás által 
végzett útvonalválasztást szeretnénk, és itt adjuk meg az útvo- 
nalat is. Ráadásul két változata is van: 


strict source routing esetén pontosan a megadott útvonalat 
kell a datagramnak bejárnia. 


loose source routing esetén a datagramnak át kell haladnia 
a megadott routereken, de közben érinthet még másokat 
is. 


4.1.3. — Transparent router 


Tekintsük a 4.2. ábra szerinti hálózatot. Az alaphálózat egy 
WAN, amelyhez egy speciális routeren (T) keresztül egy LAN-t 
kapcsolunk. A LAN nem kap saját IP hálózatcímet, hanem a 
LAN gépei a WAN-hoz rendelt IP hálózatból kapnak címeket. 
A T-vel jelölt fransparent router tudja, hogy a WAN-hoz ren- 
delt IP hálózatban szereplő címek közül melyeket osztották ki 
a LAN-on levő gépeknek. Ha a WAN felől ilyen IP címre ér- 
kezik egy csomag, akkor T továbbítja azt a megfelelő gépnek. 
A T router ugyancsak átveszi a LAN-ból a WAN-ban található 
gépek IP címeire küldött üzeneteket, és továbbítja őket. 

Ilyen módon a WAN és LAN gépei nem szereznek tudomást 
arról, hogy fizikailag külön hálózaton vannak. Természetesen 
semmi akadálya annak, hogy több ilyen átlátszó routerrel több 
LAN-t is illesszünk a WAN-hoz. 

A módszer egyik hátránya, hogy mivel az átlátszó router 
az állomások számára ténylegesen láthatatlan, hiba esetén nem 
lehet ICMP üzenetekkel vizsgálni (például nem lehet ping-elni). 
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WAN 1. [7 je 


4.2. ábra. Transparent router 


4.1.4. . Proxy ARP 


A módszer csak abban az esetben használható, ha a hálózat 
ARP-t használ az IP cím - MAC cím leképzésre. (Ez általá- 
ban fennáll.) Adott egy hálózatcímünk és két fizikai hálóza- 
tunk, amelyeket egy proxy ARP-t futtató router kapcsol össze: 
4.3. ábra. 


A B] ]c 


proxy ARP-t 
futtató 
router 
éz kae 
! 
1 





D I E I F 


4.3. ábra. Proxy ARP 


Amikor egy gép (legyen most , A" egy olyan gép (legyen 
most ,D") IP címéhez tartozó MAC címet kérdezi meg ARP- 
vel, amely gép nem vele azonos fizikai hálózaton van, az ARP 
broadcast üzenetre a keresett , D" gép helyett (amely ezt az 
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üzenetet nem kapja meg) a proxy ARP-t futtató router válaszol, 
méghozzá a kért MAC cím helyett a saját MAC címét adja meg. 
A becsapott ,A" gép így a routernek továbbítja az üzenetet, 
amely továbbadja azt a másik fizikai hálózaton lévő , D" gép 
számára. 

A két külön fizikai hálózaton lévő gépek most sem érzéke- 
lik a köztük lévő routert. A proxy ARP-t futtató router sem 
vizsgálható ICMP üzenetekkel. 

Mindkét módszer (a transparent router és a proxy ARP) 
hátránya, hogy az egységes útvonalválasztási algoritmus helyett 


attól eltérő pótmegoldást használ, ami ráadásul nagyobb számú 
fizikai hálózatnál egyre bonyolultabbá válik. 


4.1.5. Alhálózati útvonalválasztás 
A módszer lényege 


Láttuk, hogy bár eredetileg logikus volt az IP cím osztályok 
használata, ez korláttá vált, mivel egy intézmény hálózata több 
fizikai hálózatra bomlik. Kövesse akkor ezt az IP címek kezelése 
is! Bontsuk fel az IP címeknek eredetileg a hálózaton belül a 
gépek azonosítására használt gépcím részét két részre: a háló- 
zatcím felé eső rész legyen az alhálózat cím, a jobb oldali része 
pedig legyen a gépcím. (4.4. ábra) 


NETWORK HOST 





IP cím; SUBNETWORK ADDRESS HOST ADDRESS 


mask: 1] 11 00. ...00 


4.4. ábra. IP cím gépcím részének felbontása 


Korábban a hálózatcím és a gépcím határát az IP címek osz- 
tálya alapján tudtuk meghatározni. Emlékezzünk rá, hogy erre 
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feltétlenül szükségünk van az útvonalválasztásnál: a cél IP cím 
helyett annak hálózatcím részét hasonlítottuk a routing táblá- 
ban levő hálózatcímhez. Erre most is szükségünk lesz. Mi al- 
kotja most a hálózatcímet? Az osztály alapján is hálózatcímnek 
tekintett rész és az alhálózat cím együtt. Tehát az új értelemben 
vett hálózatcímet úgy kapjuk meg egy IP címből, ha kinulláz- 
zuk a most gépcímnek tekintett részt. Ehhez be kell vezetnünk 
egy további fogalmat, ez az alhálózati maszk (subnet mask). 
Ez ugyanolyan hosszú (32 bit) mint az IP cím, 1-eseket tartal- 
maz a (kibővített) hálózatcím megtartandó bitjeinek a helyén, 
és 0-kat tartalmaz a (lerövidített) gépcím bitjeinek a helyén. 
(Ez is látható a 4.4. ábrán.) így ha az IP cím és az alhálózati 
maszk között bitenkénti logikai ÉS műveletet végzünk, akkor az 
eredmény a kívánt hálózatcím lesz. 


Természetesen módosítani kell a routing algoritmust, és ki 
kell bővítenünk a routing táblát is. Nézzünk meg egy példát 
erre! A 4.5. ábrán látható 4 fizikai hálózatot 3 router kap- 
csolja össze. Ezekhez a fizikai hálózatokhoz különböző ,A", ,,B" 
és , C" osztályú hálózatokból képzett alhálózat címeket rendel- 
tünk. Vegyük észre, hogy egy alhálózat címének megadásához 
hozzátartozik a subnet mask megadása is! A subnet maskkal 


kibővített routing táblák a 4.4. - 4.6. táblázatokban láthatók. 





subnet mask dest. netw. addr. !] next hop address 
255.255.255.0 15.26.42.0 direct delivery 
255.255.255.0 156.168.12.0 direct delivery 
255.255.255.224 193.224.128.96 15.26.42.7 
255.255.255.192 ] 202.202.202.128 15.26.42.7 
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15.26.42.28 


77 — Network: 15.26.42.0 
, Mask: 255.255.255.0 


(7 Network: 193.224.128.96 


—e Mask: 255.255.255.224 A fő 
9 íz : szí B 


19 


193.224.128.102 


4.5. ábra. 


subnet mask 
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R, 156.168.12.§ 
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- Network: 156.168.12.0 : 
, Mask: 255.255.255.0. 


. 15.26.42.7 
ÍR; 
"193.224.128.100 


. B. R:l a 


3.224.128.102 


Network: 202.202.202.128 


7 Mask; 255.255.255.192. 


NN di 
9. ltszztjsttő 


202.202.202.153 


202.202.202.153 


Subneteket tartalmazó IP hálózat 


dest. netw. addr. 


next hop address 





255.255.255.0 

255.255.255.0 
255.255.255.224 
255.255.255.192 


15.26.42.0 
156.168.12.0 
193.224.128.96 
202.202.202.128 





direct delivery 
15.26.42.28 

direct delivery 

193.224.128.102 





4.5. táblázat. R? routing táblázata 


subnet mask J dest. netw. addr. J next hop address 





255.255.255.0 

255.255.255.0 
255.255.255.224 
255.255.255.192 


15.26.42.0 
156.168.12.0 
193.224.128.96 
202.202.202.128 


193.224.128.100 
193.224.128.100 
direct delivery 
direct delivery 


4.6. táblázat. R; routing táblázata 
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A subnet routing algoritmusa 


e. datagram cél IP címének megállapítása 
." ciklus a táblázat soraira 


— bitenkénti logikai ÉS művelet a cél IP cím és a subnet 
mask között 


— eredmény összehasonlítása a destination network cí- 
mével 


X egyezés esetén next hop address szerinti továb- 
bítás, és a ciklusból kilépés 

xx ha nem egyezett, akkor a ciklus folytatása, ha 
van még sor a táblázatban 


e. hibajelzés, ha nem sikerült továbbítani 


A korábbihoz hasonlóan az utolsó lépésben a router itt is 
közvetlenül a címzettnek kézbesít. Ez azért érdekes, mert min- 
den más esetben a táblázat next hop address mezőjéből kiolva- 
sott IP című routernek kell küldeni, itt viszont a datagramban 


szereplő cél IP címet birtokló gépnek. 


Példa 


Játsszunk el egy példát! 

Forráscím: 156.168.12.31 Célcím: 193.224.128.102 

Az R, router megkapja a datagramot és megállapítja a cél 
IP címet: 193.224.128.102 

R, ciklust kezd a routing táblájának a soraira. 

Az első sorban található subnet mask és a cél IP cím között 
bitenkénti logikai ÉS műveletet végez: 
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193 224 128 102 
! ! ! l 
11000001  11100000  10000000 01100110 
255 259 255 0 
l [ij j 
4 [3 4 
dc 1IILIIIL 0 TILIILII ÚLILIÍ111. 00000000 


11000001 — 11100000.— 10000000.00000000 
( ! 





f i 
4 ] 4 i 
193 224 128 0 


Az első bejegyzésben a célhálózat IP címe 15.26.42.0 nem azonos 
a számítottal, ezért vizsgálja a következő bejegyzést. 

Mivel a mask itt azonos az előző bejegyzésnél találhatóval, a 
számítást nem ismételjük meg (a router természetesen elvégzi). 
Az eredmény (193.224.128.0) most sem egyezik meg a célhálózat 
IP címével (156.168.12.0), ezért a ciklus folytatódik. 

R, bitenkénti logikai ÉS műveletet végez a cél IP cím és 
routing táblájának harmadik sorában található subnet mask kö- 


zött: 
193 224 128 102 
ii l 1 d 
11600001 — 111090000 —160006000  01100110 
255 255 255 224 
l a 1) 1 


őz  1211I111 IIL11121 IL11111211 11100000 
11000001 — 11100000 —10000000 01100000 


l l tl l 
193 224 128 96 





Az eredmény egyezik a routing tábla harmadik sorában talál- 
ható cél hálózat cím bejegyzéssel, ezért a next hop address sze- 
rinti 15.26.42.7-es IP című router felé továbbítja. 

Az olvasót bátorítjuk a datagram útjának teljes lejátszására! 
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Hálózatcímek egyszerűsített írásmódja 


Vegyük észre, hogy a szubnet maszk (subnet mask) balról jobbra 
egy határig csupa 1I-est, utána pedig csupa 0-t tartalmaz. Ezért 
ha megadjuk, hogy hány darab I-es van a maszkban, azzal a 
maszkot egyértelműen meghatároztuk. Amennyiben az egyesek 
számát az IP cím után írjuk egy per jellel (,/") elválasztva, ak- 
kor az alhálózatot egyértelműen, de rövidebb írásmóddal tudjuk 
megjelölni. 
Lássunk egy példát! Ahelyett, hogy: 


IP: 152.66.148.0 
mask: 255.255.252.0 


azt írhatjuk, hogy: 


152.66.148.0/22 


4.1.6. Classless Inter-Domain Routing 
Supernetting 


Az alhálózatokra bontásnál (subnetting) az volt a célunk, hogy 
IP cím osztályok szerint tekintve egyetlen hálózatból több há- 
lózatot hozzunk létre. 

Most nézzük meg a másik irányt! Tegyük fel, hogy 1000 
gép számára van szükségünk IP címre. Mivel a ,, B" osztályú IP 
címek már régen elfogytak, C osztályúakat kaphatunk. Ha eze- 
ket megfelelően választjuk meg, akkor lehetőségünk van, hogy a 
subnettinghez teljesen hasonló technikával a kapott négy C osz- 
tályú hálózatot egyetlen hálózattá vonjuk össze:  supernetting. 

Nézzük meg egy számpéldán, hogyan is tehetjük meg ezt! 
Legyen a négy hálózat a következő: 


193.224.128.0 
193.224.129.0 
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193.224.130.0 
193.224.131.0 


Az összevont hálózat ekkor: 
193:224.12850/22. 


Vegyük észre, hogy ez nem tehető meg tetszőleges számú egy- 
mást követő hálózat esetében. Feltétel, hogy az összevonandó 
hálózatok együttesen folytonos, kettő hatvány méretű és kettő 
hatvány határra illesztett blokkot alkossanak. — Viszont nem 
szükséges, hogy azonos méretűek legyenek! így például a fenti 
eredményt kapjuk az alábbi hálózatok összevonásával is: 


193.224.128.0/24 
193.224.129.0/26 
193.224.129.64/26 
193.224.129.128/26 
193.224.129.192/26 
193.224.130.0/25 
193.224.130.128/25 
193.224.131.0/24 


CIDR 


A két megoldás (subnetting és supernetting) során ugyanúgy 
használjuk a maszkolást, így a subnettingnél tanult útvonalvá- 
lasztási algoritmus (subnet routing) módosítás nélkül használ- 
ható a supernetting esetén is. Sőt, meg sem kell különböztet- 
nünk, hogy a kettő közül melyikkel nyertük a hálózatcímet: tel- 
jesen elfeledkezhetünk az IP cím osztályokról. Osztály nélküli 
címzést (classless addressing) és osztály nélküli útvonalválasz- 
tást (Classless Inter-Domain Routing - CIDR, RFC-k: 1517 - 
1520) használhatunk. Ennek megfelelően módosulnak a megne- 
vezések is. Többé már nem beszélünk hálózatcímről (network 
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address) és alhálózatcímről (subnetwork address), hanem az IP 
címeink két részből állnak: a hálózati prefixből és a gépcímből 
(úgy mint eredetileg az RFC 791-ben, csak már nem az osztá- 
lyok alapján választjuk szét őket): 


IP-address ::— ( -Network-prefixz, -Host-numbers: ) 








Bár a CIDR lehetővé tenné a teljes 32 bites címtartomány 
használatát, ettől még az IP címek kiosztásánál továbbra is csak 
az egykori ,A", , B" és , C" osztályú tartományokat osztják ki 
felhasználásra, a , D" osztályba tartozó IP címek továbbra is 
multicast címek, az , E" pedig fenntartott (használaton kívüli). 

A CIDR még azt is lehetővé teszi, hogy a routing táblában 
olyan célokat (hálózatcímtmaszk) adjunk meg, amelyek között 
tartalmazási reláció van. Ezek közül a nagyobb hálózatot, tehát 
aminek rövidebb a hálózati prefixe (és ami több címet tartal- 
maz) nevezzük a kevésbé specifikusnak, és a kisebb hálózatot, 
tehát aminek hosszabb a hálózati prefixe (és ami kevesebb címet 
tartalmaz) nevezzük a specifikusabbnak. Az RFC 1812 előírja, 
hogy ilyen esetben a routereknek a legspecifikusabb illeszkedő 
cél felé kell a forgalmat irányítaniuk." 

A hálózatok közötti tartalmazási reláció lehetősége óriási je- 
lentőségű. Ezzel sikerült az eredeti IP két szintű hierarchikus 
címzését több szintűvé tenni. így ami távolról egy hálózatnak 
látszik, az közelről több hálózatra válhat szét, és viszont: egy 
adott rendszeren belül található több kisebb hálózat kívülről 
egynek látszik. Ez középtávon megoldást jelent arra a problé- 
mára, amit a hálózatok számának növekedése okozott a route- 
reknek. 


? Az RFC 1812-ben a 2.2.5.2. szól a CIDR témáról, de érdemes ta- 
nulmányozni az egész 1812-es RFC-t html formázásban, így egy jól át- 
tekinthető összefoglalót kapunk az útvonalválasztásról. Elérhető például: 
http://www.freesoft.org/CIE/RFC/1812/index.htm 
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Történeti áttekintés 


Természetesen már régóta a CIDR szerint működnek a háló- 
zataink. Egy rövid történeti összefoglaló a fejlődés lépéseiről, 
átvéve [33]-ből: 


. 1980 - Classful Addressing, RFC 791 


e 1985 - Subnetting, RFC 950 


e 1993 - Classless Addressing (CIDR), RFCs 1517-1520 


Privát IP címek - más jelöléssel 


Most már fel tudjuk írni az RFC 1918-ban megadott privát, 
(más szóval nem publikus vagy nem routolható?) IP címek tar- 
tományát a CIDR jelöléssel: 


e 7]0.0.0.0/8 vagy más néven: 170/8 prefix 
sőt úgy is nevezik, hogy: 24 bites blokk 


e 1]72.16.0.0/12 vagy 172.16/12 prefix 
ez pedig a 20 bites blokk 


. 1792.168.0.0/16 vagy 192.168/16 prefix 
ezt meg természetesen úgy hívják, hogy: 176 bites blokk 


"Természetesen a belső hálózatok routerei kezelik őket, csak az Internet 
gerinchálózati routerei dobják el az ilyen címekre küldött datagramokat. 
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4.2. — Útvonalválasztási táblázatok kialakí- 
tása 


Természetesen a routerek routing táblázatait nem a rendszer- 
gazdák töltik fel kézzel, hanem léteznek olyan protokollok, amik 
segítségével a routerek kicserélik egymással az információikat a 
hálózatokról, és , kitalálják", hogy melyik hálózat fele milyen 
irányba kell küldeni a csomagokat. Mielőtt ezekkel a protokol- 
lokkal megismerkednénk, meg kell értenünk néhány alapfogal- 
mat. 


Először is azzal kezdjük, hogy az RFC-kben a routereket 
gatewayeknek nevezik. A 4.6. ábrán rövidítve szereplő fogalmak 
megnevezése és magyarázata a következő: 


AS - Autonomous System (önálló rendszer) 
Az egy adminisztratív hatóság (Administrative Authority) 
felügyelete alatt álló rendszer. 


IGP — Interior Gateway Protocol (belső routerek közötti 
protokoll) Az azonos AS-ben lévő routerek egymás között 
ezzel a protokollal cserélnek útvonal-információt. Ezt az 


AS-t felügyelő adminisztratív hatóság választhatja meg. 


EGP - Exterior Gateway Protocol (külső routerek közötti 
protokoll) Az AS-ek határán levő routerek ezzel a proto- 
kollal cserélnek útvonal-információt a velük szomszédos 
AS-ek határ routereivel (border gateway). 


Az IGP és az EGP nem egy-egy protokollt, hanem egy- 
egy protokoll kategóriát jelölnek. IGP-ből kettőt (RIP, OSPF) 
EGP-ből egyet (BGP) fogunk megismerni. Azt is látni fogjuk, 
hogy az IGP és az EGP kategóriákba tartozó protokollokkal 


b. 


szemben eltérőek a követelmények. 
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AS, AS, 
8. gp 16 0 
eteb EGP (R j 
s Ir 
r A aze 


4.6. ábra. Alapfogalmak útvonalválasztási protokollokhoz. For- 
rás: [4] 


4.2.1. Routing Information Protocol 


Amint a neve is kifejezi, a Routing Information Protocol célja 
az, hogy a routerek ennek segítségével átadhassák egymásnak 
az útvonalválasztással kapcsolatos információikat. 

A RIP egy IGP, azaz autonóm rendszeren belül működik, 
sőt alapvetően lokális hálózatokra tervezték, mivel a protokoll 
üzenetszórást használ az információcseréhez. 

Az útvonal hosszát az átmenő routerek számával határozza 
meg (hop-count). Valamely hálózat felé irányuló útból min- 
dig csak a következő router címét tárolja (amely router felé a 
datagramot majd továbbítania kell). 

A továbbiakban a RIP 2-es verziójával foglalkozunk (RIPv2), 
amely a hálózatcímekkel együtt a netmaskot is továbbítja és 
kezeli (RFC 1388). (Az eredeti, RFC 1058-ban leírt RIP nem 
továbbított netmaskot.) 


Egy RIP-es router működése 


" A router üzenetszórás (broadcast) segítségével megosztja 
a többi routerrel, hogy mely hálózatokat lát közvetlenül 
(amelyek hozzá csatlakoznak). 
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e Tanul, azaz: 


- ha (egy másik router broadcast üzenetéből) tudo- 
mást szerez egy eddig még ismeretlen hálózatról, ak- 
kor eltárolja azt (netmask - network prefix) az útvo- 
nal hosszával és kezdő lépésével (next hop address) 
együtt. (A kezdő lépés az a router, amely a felhasz- 
nált broadcast üzenetet küldte, azon keresztül fogja 
elérni. A hossz pedig 1-el nagyobb, mint amilyen 
távolságban az útvonalat hirdető router látta.) 


— ha tudomást szerez egy már ismert hálózat felé az el- 
tároltnál rövidebb útról, akkor az eltároltat kicseréli 
erre. 


," A saját információit broadcasttal továbbadja a többiek- 
nek: azt is, amit tanult. 


Korlátai 


. egy hálózat felé csak egy útvonal lehetséges 
Mivel csak a meglevőnél rövidebb új útvonal esetén cserél, 
az azonos hosszúságú újabb útvonalat nem tárolja el. 


, csak a hop countot használja távolsági mérőszámként 
Ez az egy mérőszám nem jellemez elég jól: átviteli sebes- 
séget, fizikai távolságot nem veszi figyelembe. 


e az üzenetszórás csak LAN esetén működik (hatékonyan) 
Természetesen egyenként elküldheti az útvonal informá- 
ciót minden szomszédjának, de az már kevésbé hatékony 
megoldás. 


." nagy hálózat esetén nem használható 
Ha a hálózat mérete (fizikai hálózatok száma) nő, akkor a 
RIP hatékonysága csökken, bizonyos hálózatméret felett 
a hálózatot teljesen megtöltené a RIP forgalom. 
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Példa 


Nézzünk meg egy példát a RIP működésére! A 4.7. ábrán lát- 
ható hálózat RIP-et használ. Játsszuk le a RIP működését! 
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4.7. ábra. Példahálózat RIP-hez 


Megoldás: Készítsünk egy táblázatot, aminek a vízszintes 
fejrészén feltüntetjük a routereket, a függőleges fejrészén pedig 
a hálózatokat. Első lépésben minden routerhez beírhatjuk, hogy 
közvetlenül látják azokat a hálózatokat, amelyekhez kapcsolód- 
nak. Tehát minden router oszlopába a hozzájuk kapcsolódó 
hálózatok sorába beírjuk, hogy: ,,1(k)", ami azt jelenti, hogy az 
adott routeren keresztül 1 távolságban és közvetlen kézbesítéssel 
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elérhető az adott hálózat. A routerek időről időre üzenetszórás- 
sal közzéteszik (broadcastolják), amit tudnak. Ha például R, 
megkapja R, adatait, akkor például R.-nek a 152.66.3.0/24 há- 
lózat felé irányuló ,,1(k)" bejegyzése alapján a saját táblázatába 
a 152.66.3.0/24 sorába beírhatja, hogy ,,2(2)", ahol az első 2-es 
azt jelenti, hogy 2 távolságban érhető el, a második 2-es pedig 
azt, hogy R,-n keresztül. Természetesen egy valódi router az 
itt zárójelben szereplő szám helyett az illető router (megfelelő 
interfészének) IP címét írja be a táblázatába, esetünkben ez az 
R, router R, felé eső hálózati interfészének a címe: 152.66.2.2. 
Honnan tudja ezt? Az R.-től kapott RIP üzenetben szerepel. 
(Mi most az IP cím helyett a router sorszámát használjuk, így 
sokkal kevesebbet kell írni.) Az Olvasót bátorítjuk arra, hogy 
papíron tényleg játsszon el a feladattal. Célszerű ceruzát hasz- 
nálnia, hogy tudjon törölni. A 4.7. táblázatban egy már részle- 
gesen kitöltött táblázat látható. 
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4.7. táblázat. RIP-es gyakorló feladat részleges megoldása 
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Felhívjuk a figyelmet néhány tényre: 


Amint a táblázatba bekerültek a routerek által közvetle- 
nül elérhető hálózatok bejegyzései, többé már nem a há- 
lózat rajza alapján kell dolgozni, hanem a routerek egy- 
mástól kapott információi alapján (a rajz természetesen 
ellenőrzésként használható). 


A táblázat a rendszerben sehol sem létezik, minden router 
csak a táblázatban a neve alatt szereplő oszlopot ismeri. 


4. 


Az Olvasó kaphat a 4.7. táblázattól eltérő részeredményt, 
ami nem feltétlenül jelent hibát. Még a végeredmény 
is függ attól, hogy az egyes routerek milyen sorrendben 
kapták meg mások információit. (Gondoljunk arra, hogy 
egyenlő távolságnál nem cserélünk.) Ez a valóságban is 
így van. 


4.2.2. Open Shortest Path First 


Az IGP egy másik fajtája az OSPF (Open Shortest Path First). 
Ez sokkal többre képes, de ugyanakkor lényegesen bonyolultabb 
protokoll, így nem fogjuk részletesen megismerni a működését. 


d84 


Először néhány fontosabb jellemzőjét tekintjük át: 


nyílt (Open), azaz szabadon, ingyenesen hozzáférhető 


nem csak egy, hanem több út is lehetséges adott cél háló- 
zat felé, ezek között adott szempont szerint lehet válasz- 
tani (lásd következő kettő) 


Type of Service figyelembe vétele 


terhelés egyenletes elosztásának támogatása (load balanc- 
ing) 


hierarchikus felépítés —2 méretnövekedés támogatása 
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." authentikáció (router azonosítás) —2 véd a routerek kö- 
zötti hamis információcsere (távolságvektor) ellen! 


. figyelembe veszi, hogy egy hálózat támogatja-e az üzenet- 
szórást vagy nem (ha igen, használja, ha nem, akkor más 
megoldást alkalmaz) 


Működése során a hálózatokat három kategóriába sorolja: 
. Pont-pont közötti összeköttetés 


. Többszörös hozzáférésű hálózatok adatszórási lehetőség- 
gel (LAN) 


. Többszörös hozzáférésű hálózatok adatszórási lehetőség 
nélkül 


vo z 


Most röviden (és leegyszerűsítve) összefoglaljuk hogyan mű- 
ködik az OSPF. Az AS-et ferületekre (area) osztja. Az area 
több együttesen kezelt hálózatot jelent. Minden area kapcso- 
lódik a backbone areához (gerinchálózat). Az összes router ér- 
zékeli a hozzá kapcsolt vonalak állapotát (link state) és hirdeti 
a többiek számára, de csak az areán belül. így az egy areán 
belül található összes router ismeri az areát alkotó hálózatok 
topológiáját, és a topológiájukat leíró gráfon az ún. Dijkstra 
algoritmussal kiszámolja a legrövidebb utakat. A területeket a 
terület határ routerek (area border router) kapcsolják a gerinc- 
hálózathoz. Ezek a többi területhatár router elől elrejtik a saját 
területük belső felépítését (mintha az egyes területek pontsze- 
rűek lennének). A gerinchálózaton (backbone area) is teljesen 
hasonlóan határozzák meg a legrövidebb utakat. Lehetséges 
még külső útvonalak hirdetése is. A protokollt kapcsolat állapot 
(link state) alapú protokollnak is nevezik szemben a RIP-pel 
és a BGP-vel, amelyek távolság vektor (distance vector) alapú 
protokollok. 
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4.2.3. Border Gateway Protocol 


Az EGP egyik fajtája a BGP (Border Gateway Protocol). 

Egy EGP-nél mások a szempontok, mint egy IGP terve- 
zésénél, itt figyelembe kell venni a topológián túl a gazdasági 
(költségkihatás), és politikai (ellenség felé ne forgalmazzon) né- 
zőpontokat is. Nézzünk erre egy példát! Tekintsünk 3 auto- 
nóm rendszert: , A", , B" és , C", melyek mindegyike mindegyik- 
kel össze van kötve, de , C"-nek a világ többi része felé való 
összeköttetését ,A" biztosítja, a ,,B"-, C" link csak , B" és ,C" 
közti forgalom direkt továbbítását szolgálja. Ha az ,A"-, B" 4 
5 B -,C" link összesen jobb, mint az , A"-, C", akkor egy közönsé- 
ges routing protokoll azt választaná a , C" és a világ többi része 
közti forgalom továbbítására, ezzel szemben a BGP biztosítja, 
hogy ne úgy legyen, ha a felek nem azt kívánják: policy routing. 

Az AS-ek bekötésük szempontjából három osztályba sorol- 
hatók: 


stub (csonk) csak egy bekötése van, végfelhasználók felé ad 
internet elérést 


multi-connected több bekötése van, de nem enged átmenő 
forgalmat. 


transit tranzit, azaz átmenő hálózat, éppen az a célja, hogy 
más hálózatok forgalmát szállítsa 


5. fejezet 


További témakörök 


A továbbiakban még röviden áttekintünk néhány fontos és ér- 
dekes témakört, amelyek részletes tárgyalásával e jegyzet ke- 
retében már nem tudunk foglalkozni. Az érdeklődők ezeket 
alaposabban is megismerhetik az irodalomjegyzékben megadott 
forrásokból, illetve a választott szakiránytól függően elmélyed- 
hetnek bennük a tanulmányaik során. 


A távközlés-informatika szakirányon részletesen tárgyaljuk 
a hálózati alkalmazásokat és azok protokolljait a Protokollok és 
szoftverek tárgy keretében. A szolgáltatások nyújtásával, a szer- 
verek beállításával a Hálózati operációs rendszerek, az aktív há- 
lózati eszközök bekonfigurálásával a Kommunikációs rendszerek 
programozása, a biztonsági kérdésekkel pedig a Hálózatok biz- 
tonsága tárgy foglalkozik. Bővebb információ található a szak- 
irány honlapján: [20]. 


Szakdolgozat készítés vagy tudományos diákkör keretében 
pedig hallgatóink önálló alkotó- és/vagy kutatómunkát végez- 
hetnek azokon a területeken, amelyeket e jegyzet elején a szá- 
mítógép-hálózatok céljaként, feladataként jelöltünk meg. 
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5.1. Hálózati alkalmazások 


A megelőző fejezetekben tanultak feladata, hogy a hálózati al- 
kalmazások számára biztosítsák a kommunikációt. 

A hálózati alkalmazások többsége a kliens-szerver modell 
szerint működik, azaz egy szerver alkalmazás nyújt valamilyen 
szolgáltatást, amelyet a hálózaton keresztül hozzá kapcsolódó 
kliensek tudnak igénybe venni. 

Hogyan találja meg egy kliens a szervert? Általában a kli- 
ensnek (illetve a kliens programot használó felhasználónak) tud- 
nia kell, hogy az igénybe venni kívánt szerver program melyik 
számítógépen fut. A számítógépekre az IP címük helyett a 
szimbolikus nevükkel hivatkozhatunk: ezt részletesen tárgyal- 
juk az 5.1.2-ben. Egy gépen akár több szolgáltatás is futhat; a 
kliens program az általa kívánt szolgáltatást nyújtó szervert a 
portszám segítségével találja meg. 


5.1.I. . A portszámok kiosztása 


A portszámok kiosztásáért a korábban már említett IANA [27] 
felelős. Honlapján a portszámok kiosztásán kívül nagyon sok 
más információ is megtalálható, javasoljuk a tanulmányozását. 
A honlapról a portszámok kiosztásának módja és a kiosztás ak- 
tuális állása is elérhető: [241]. 

A portszámokat három tartományra bontották: 


Well Known Ports ,jól ismert" portok: 0-1023 
Ezeket a portokat használják az alapvető, általánosan hasz- 
nált hálózati szolgáltatások. Ezekhez a portokhoz csak 
privilegizált (Unix alatt például root jogokkal elindított) 
szerver programok kapcsolódhatnak. 
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Registered Ports regisztrált portok:  1024-49151 
Ezeken a portokon egyéb szolgáltatások érhetők el. Ha va- 
laki kitalál egy szolgáltatást, igényelhet hozzá ilyen port- 
számot. Ezeken a portokon történő szolgáltatásnyújtás- 
hoz nem szükséges privilegizált módban futtatni a szerver 
programot. 


Dynamic Ports dinamikusan kiosztott portok: 49152-65535 
Ebből a tartományból az operációs rendszer oszt ki por- 
tokat a kommunikációhoz a programoknak. 


A továbbiakban csak olyan hálózati alkalmazásokkal foglal- 
kozunk, amelyek szerver programja valamelyik jól ismert porton 
érhető el. 

Az 5.1. táblázatban tájékoztatásul megadjuk néhány fonto- 
sabb hálózati alkalmazás portszámát, valamint az alkalmazások 
rövidített és teljes nevét. 





port ! alk. röv. ! hálózati alkalmazás neve 











20 ! FTP File Transfer Protocol, data 
21 I! FIP File Transfer Protocol, control 
22 1! SSH Secure Shell 





23 ) Telnet Telnet 

25 ! SMTP Simple Mail Transfer Protocol 

80 ] HTTP HyperText Transfer Protocol 
110 ] POP3 Post Office Protocol - Version 3 
143 ] IMAP4ÁA ] Internet Message Access Protocol - 
Version 4 
443 ) HTTPS ! HTTP over TLS/SSL 
993 ] IMAPS ] IMAPA over TLS/SSL 

995 ] POP3S POP3 over TLS/SSL 






































5.1. táblázat. Néhány fontosabb hálózati alkalmazás portszáma 
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A továbbiakban a hálózati alkalmazások leírásához felhasz- 
nált forrás: [15] 
5.1.2. . Domain Name System 


Mivel az IP címek az emberek számára nehezen megjegyezhető k, 
ezért a számítógépeket az IP cím helyett a sokkal könnyebben 
megjegyezhető szimbolikus névvel azonosítjuk. 


A szimbolikus nevek 


Hogyan épülnek fel a szimbolikus nevek? Példaként tekintsük 
a következó t: 


itanium.tilb.sze.hu 








A név mezőit pontok választják el. Az első mező jelenti 
a gép (host) nevét (itanium), a többi a fartomány (domain) 
neve. A tartományok felépítése hierarchikus, fa struktúrát kö- 
vet. Az 5.1. ábrán látható, hogy a legfelső szinten egy pont (,,.") 
van, amit a nevek írásakor elhagyunk. Alatta vannak a /eg- 
Jfelső szintű domain-ek (TLD: Top Level Domain). Ezek további 
domain-ekre bomlanak, ami tetszőleges mélységig folytatható. 
Az ábrán értelemszerűen a , hu" Magyarországot, a , sze" a Szé- 
chenyi István Egyetemet, a , tilb" pedig a Távközlés-informatika 
Labort jelenti. Egy számítógép teljes nevét (FODN: Fully 
Oualified Domain Name) tehát a gép nevétől a fa struktúrá- 
ban felfele haladva olvassuk ki, az egyes mezők közé pontot 
teszünk, és a végét is ponttal zárjuk! A végén álló pont teszi 
formálisan egyértelművé, hogy egy FODN-nel állunk szemben. 
A gyakorlatban a pontot el szoktuk hagyni. 

A TLD neveknek két fajtája van. A generic TLD (gTLD) 
nevek a szervezetek fajtája szerinti csoportosítást használják, 


" Nehéz rá jó magyar kifejezést találni, lehetne például teljesen kifejtett 
névnek hívni, a legbiztosabb, ha FODN-nek hívjuk. 
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com net 


org hu de uk 


8 j 
bme sze 


rsi ulb MV 


cami cam2 — itanítm 


5.1. ábra. A DNS névhierarchia egy részlete 
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erre bemutatunk néhány példát az 5.2. táblázatban. Mivel az 
Internet eredetileg az USA-ban indult, ezek eredetileg ottani 
kategóriákat jelentettek, aztán bizonyosak az egész világon el- 
terjedtté váltak, de van amelyik (például gov) ma is csak az 
USA-ban használatos. A country code TLD (ccTLD) nevek az 
ITU (International Telecommunication Union) illetve az ISO 
3166 szabvány szerinti két betűs ország megjelölést követik (ki- 
vétel: gb helyett inkább uk-t használnak), az 5.1. ábrán ilyenek: 


hu, de, uk. 





gTLD 


szervezet fajtája 





com 


üzleti vállalkozás 





org 


non-profit szervezet 





net 


hálózattal kapcsolatos 





edu 


oktatási intézmény 








gov 








USA közigazgatás 





5.2. táblázat. Példák generic TLD-re 
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A névfeloldás 


Hogyan történik a névfeloldás? Amikor egy programnak szük- 
sége van valamilyen szimbolikus névhez tartozó IP címre, akkor 
meghívja a megfelelő könyvtári függvényt. Operációs rend- 
szertől függően a részletekben eltérés lehet, mi most a Linux 
példáján mutatjuk be a továbbiakat. A névfeloldó (name resol- 
ver) a megfelelő konfigurációs fájl! alapján eldönti, hogy milyen 
sorrendben próbálkozzon a különböző lehetőségekkel. A tipi- 
kus beállítás szerinti sorrend esetén először helyi fájlból! kísérli 
meg feloldani, ha nem sikerül, akkor a /etc/resolv.conf fájl- 
ban beállított névkiszolgálót kérdezi meg. A gép a továbbiakból 
csak annyit érzékel, hogy a névkiszolgáló válaszol: megadja a 
keresett IP címet, vagy jelzi, hogy az adott szimbolikus névhez 
nem található IP cím. 

Mivel a hálózati alkalmazások kliens-szerver kommunikáci- 
ójának alapvető működése nagyon hasonló, ezért a DNS példá- 
ján keresztül a többihez is közelebb kerülünk. Kövessük tehát 
nyomon a kliens és a szerver kommunikációját! Az 5.2. ábrán 
látható, hogy a névkiszolgáló az 53-as porton érhető el. A kliens 
tehát megkérdezi a szervert, amire a szerver válaszol. A kommu- 
nikáció a többi hálózati alkalmazás esetén is hasonlóan történik, 
de ott természetesen más a szerver portszáma, és más a kliens- 
szerver kommunikáció protokollja is. További különbség, hogy a 
DNS-sel ellentétben az alkalmazások többsége TCP-t használ, 
mert megbízható átvitelre van szüksége. Itt azért célszerűbb 
az UDP, mert egy rövid (egy adategységben átvihető) kérdésre 
egy rövid választ várunk, és ha esetleg valamelyik elveszik is, 
akkor majd megkérdezzük újra. A DNS tehát általában UDP-t 
használ a name resolver és a name server között, mert a 7CP 
overhead (a kapcsolat felépítése és bontása) túl nagy lenne, de 


Unix esetén ez a gethostbyname() függvény. 
régebben: /etc/host.conf, újabban /etc/nsswitch.conf 
/etc/hosts 
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olyan esetekben, amikor a name resolver tudja, hogy több ké- 
rést is fog küldeni, akkor általában TCP-t használ. (Például a 
netstat" parancs esetén.) 


Flt" 
f alkal- 4 
/ j 
4 mazás / 
sző 


UDP 
IP 





5.2. ábra. DNS kliens-szerver kapcsolat 


Nézzük meg most azt, hogy a szerver hogyan tudja megadni 
a választ a kliens kérdésére. Ehhez tudnunk kell, hogy a DNS 
egy világméretű elosztott adatbázis. A névkiszolgálók egy ré- 
sze" felelős egy vagy több zónába tartozó nevek feloldásáért. A 
zóna nem egyezik meg a domainnel. A különbséget egy példá- 
val világítjuk meg. Az 5.1. ábrán a sze.hu domainhe tartozik 
mindaz, aminek a neve sze.hu-ra végződik: 


rs1.sze.hu 
cami1.tilb.sze.hu 
cam2.tilb.sze.hu 
itanium.tilb.sze.hu 


"lásd: A.3. függelék 
"Nem mindegyik, lásd a 150. oldalon: cacheing only name serverek. 
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www.sze.hu 


A sze . hu zónába azonban csak az rs1 . sze . hu és a www.sze .hu 
tartozik bele, ezeket a sze.hu zónáért felelős névkiszolgáló ké- 
pes feloldani, míg a másik hármat nem ismeri, hanem delegálja 
őket a tilb.sze.hu zónáért felelős névkiszolgálónak. 


iterative gyery 






ROOT 
névkiszolgáló 


"hu zőnáért felelős 
névkiszolgáló 





Ittadiukkia 7! i helyi 
; Í névkiszolgáló 


host itaniup tílbisze.tu [1 





sze.hu zónáért felelős 


] névksszolgáló 





iterattve gucry 





ulb.sze.hu zónáért 
felelős névkiszolgáló 


authorative 
answer 


terative gucry 





4 


név 
adatbázis 


5.3. ábra. A névfeloldás folyamata 
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Kövessük végig az 5.3. ábrán, hogyan alakul a névfeloldás 
folyamata, ha valahol egy számítógép megkérdezi a helyi név- 
kiszolgálójától az itanium.tilb.sze.hu gép IP címét! A gép 
a helyi névkiszolgáló felé recursive gueryt küld, ami azt jelenti, 
hogy a névkiszolgáló feladata, hogy teljes egészében elvégezze 
a feloldást. A helyi névkiszolgáló a többi névkiszolgálót min- 
dig iterative gueryvel szólítja meg, ami azt jelenti, hogy azok 
feladata csak annyi, hogy egy lépéssel közelebb vigyék a kér- 
dezőt a feladat megoldásához a rendelkezésükre álló információ 
alapján, de nem kell más névkiszolgálóhoz fordulniuk. Tehát 
a helyi névkiszolgáló megszólítja valamelyik root névkiszolgálót 
(ilyenből több is van), amely válaszában megadja, hogy melyik 
névkiszolgáló felelős a hu zónáért. Az ilyen választ úgy hív- 
ják, hogy referral. A helyi névkiszolgáló a következő kérdést a 
hu zónáért felelős névkiszolgálóhoz intézi, amelynek válaszából 
megtudja, hogy melyik névkiszolgáló felelős a sze.hu zónáért. 
Most már a sze.hu zónáért felelős névkiszolgálót kérdezi meg, 
amely megadja, a tilb.sze.hu zónáért felelős névkiszolgáló IP 
címét. Ezt megkérdezve pedig már authoritative answert kap: 
ez a keresett IP cím. Ha mondjuk a nincsilyen.tilb.sze.hu 
gép IP címének kiderítését kíséreljük meg, a folyamat akkor is 
ugyanígy zajlik le, de a végső authoritative answer az lesz, hogy 
nincs ilyen bejegyzés. 

Néhány megjegyzés: 








1. Bár a névkiszolgálók is rendelkeznek szimbolikus névvel, 
a használat során mindig az IP címükre van szükségünk. 
A hallgatók gondolják végig, hogy mire mennénk a szim- 
bolikus nevükkel! 


2. A névfeloldás hatékonyságát cache-eléssel fokozzák: a név- 
kiszolgálók a kiderített információt az authoritative for- 
rás által megadott TTL lejártáig tárolják; legközelebb 
már nem kell megkérdezniük - ez gyorsítja a névfeloldást, 
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valamint lényegesen csökkenti a névkiszolgálók és a háló- 
zat terhelését. Létezik negatíve cache is: a nem létezést is 
tárolják, ezzel is csökkentik az authoritative name server 
terhelését. 


3. Amennyiben egy telephelyen nem foglalkoznak DNS ad- 
minisztrációval (mert például a cég központi telephelyén 
látják el, vagy az internet szolgáltatóra bízzák) akkor is 
üzemeltethetnek helyben névkiszolgálót a névfeloldás gyor- 
sítására, ezt a saját zónával nem rendelkező névkiszolgálót 
úgy hívják, hogy cacheing only name server. 


4. A DNS a bemutatottnál lényegesen bonyolultabb, pél- 
dául rendelkezik tartalékolással: minden zónát legalább 
két névkiszolgáló képes feloldani. 


5. A DNS iránt mélyebben érdeklődőknek javasoljuk a kö- 
vetkező angol nyelvű szakkönyvet: [3] 


Reverse mapping 


Bizonyos esetekben arra is szükség van, hogy az IP cím alap- 
ján határozzuk meg a szimbolikus nevet, amelyhez az IP cím 
tartozik. Ezt fordított irányú leképzésnek, angolul reverse map- 
pingnek nevezzük. A leképzés ugyanazt az infrastruktúrát hasz- 
nálja, amit a szimbolikus névről IP címre való leképzés is hasz- 
nál, méghozzá olyan módon, hogy a leképzéshez szükséges struk- 
túrát a DNS névfában az in-addr.arpa alatt hozták létre. En- 
nek részleteivel már nem tudunk foglalkozni. 


Domain regisztráció 


Ismerjünk meg néhány fontos fogalmat a regisztrációval kapcso- 
latban! 
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registry Egy TLD adminisztrálásának felelőse, delegálja az 
adott TLD subdomainjeit, de az ügyfelek közvetlenül nem 
fordulhatnak hozzá. 


registrar Magyarul regisztrátor, általában egy profit orientált 
cég (de akár egyesület is lehet), akihez az ügyfelek fordul- 
hatnak domain név regisztrációért. 


registration A domain név regisztráció folyamata. 


A hu domain adminisztrálásának felelőse az Internet Szol- 
gáltatók Tanácsa. Honlapján [28] megtalálható a hivatalos re- 
gisztrátorok listája, valamint a regisztrálással kapcsolatos sza- 
bályok. Az általuk közölt Domainregisztrációs szabályzat vilá- 
gos fogalom magyarázattal kezdődik, megtalálhatók az igénylés, 
a regisztrálás, a vitás esetek kezelésének szabályai, valamint 
egy domain igénylő lap minta is, amin látható, hogy mit kell 
megadni domain igényléskor (például: kért domain név, névki- 
szolgáló, többféle kapcsolattartó, számlázási cím). A honlapon 
található egy kereső is, amivel ellenőrizhetjük, hogy egy név 
szabad-e még, illetve ha már nem, akkor megtudhatjuk, hogy 
ki regisztrálta. 


5.1.3. További alkalmazások 

Nagyon röviden tárgyalunk még néhány fontosabb alkalmazást. 
Ezekre általában jellemző a már megismert kliens-szerver archi- 
tektúra és a TCP szállítási protokoll használata. 


Simple Mail Transfer Protocol 


A levelezéshez szükség van az e-mail címekre. Nézzünk meg 
erre egy egyszerű példát: 


lencsegrsi.sze.hu 
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Ebben az esetben a , 2" után az rs1l.sze.hu gép FODN-je áll, 
előtte pedig egy érvényes postafiók az említett gépen." 

A felhasználó egy levelező kliens (Mail User Agent) program 
segítségével megírja a levelet, ahol természetesen meg kell adnia 
a címzett e-mail címét is. Amikor a levelet elküldi, a levelező 
kliens az SMTP protokoll segítségével átadja a levelet a prog- 
ramban beállított kimenő SMTP szervernek (outgoing SMTP 
server). Ez egy üzenetátviteli ügynök (Message Transfer Agent) 
amely ugyancsak az SMTP protokoll segítségével eljuttatja a 
levelet a címzett leveleit kezelő levelező szervernek, amely elhe- 
lyezi azt a címzett felhasználó postafiókjába. A legegyszerűbb 
esetben a címzett belép arra a gépre, ahol a postafiókja ta- 
lálható, és a levelező kliens programja segítségével elolvassa a 
levelet. 

SMTP-nél nem garantált az átvitel, sikertelenség esetén ál- 
talában hibaüzenetet kapunk. 


POP3 és IMAP4 


A Post Office Protocol (3-as verziója) arra nyújt lehetőséget, 
hogy egy felhasználó hozzáférjen a leveleihez (elolvashassa, tö- 
rölhesse őket) anélkül, hogy be kellene lépnie a leveleit kezelő 
gépre (ahol közvetlenül elérhetné őket). Ehelyett a POP3 szer- 
ver fér hozzá közvetlenül a felhasználó postafiókjához, a felhasz- 
náló levelező programja pedig POP3 kliensként a POP3 proto- 
koll segítségével (felhasználói névvel és jelszóval azonosítva ma- 
gát) letölti a felhasználó számára a leveleket, amelyeket ezután 
a felhasználó helyben tud kezelni. A részleteket most mellőzzük. 

Az Internet Message Access Protocol (4-es verziója) a POP3- 
hoz hasonló funkciójú azzal az eltéréssel, hogy lehetővé teszi, 
hogy távolról elérjük, kezeljük a szerveren tárolt leveleinket 


A helyzet ennél lényegesen bonyolultabb is lehetne, de most nem célunk 
mélyebbre ásni. 
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és azok részeit (például csatolt fájlok), sőt arra is lehetőséget 
nyújt, hogy az egész postafiókot letöltsük és off-line módosítsuk, 
majd utána újra szikronizálhassuk a helyi és a távoli postafió- 
kot. Ezért IMAP4-et használunk akkor, ha a leveleinket több 
helyről is el szeretnénk érni. 

Használati szempontból fontos még megemlíteni, hogy be- 
állítástól függően a POP3 esetleg nyílt szövegként (titkosítás 
nélkül) átviszi a felhasználó jelszavát a hálózaton, illetve mind- 
két protokoll titkosítás nélkül viszi át a leveleket. 


File Transfer Protocol 


Az FTP segítségével fájlokat tudunk egy távoli gépről letölteni 
vagy oda feltölteni. 

A kliens-szerver kommunikációt illetően abban különbözik 
a többi tárgyalt protokolltól, hogy a kliens és szerver között két 
TCP kapcsolatot használ. A vezérlő kapcsolat a szerver 21-es 
portjára csatlakozik, és a műveletek során mindvégig fennáll. 
Az adat kapcsolat portszáma a szerveren a 20-as, és csak az 
adatátvitel idejére (fájl le- vagy feltöltés, könyvtárlista letöltése) 
jön létre, utána lebomlik. 

A felhasználó szempontjából jelentős tulajdonság, hogy az 
adatkapcsolat kiépítési iránya eldönthető. Aktív módban a kli- 
ens a vezérlőcsatornán keresztül megadja a szervernek, hogy 
milyen IP címen és milyen porton várja a szerver csatlakozását, 
és a kapcsolatot a szerver építi ki a kliens felé. Passzív módban 
éppen fordítva történik: a szerver adja meg az IP címet és port- 
számot, és a kliens kezdeményezi a TCP kapcsolat felépítését. 
Amennyiben a kliens oldalon NAT-ot vagy tűzfalat használunk, 
csak passzív módban tudjuk az FTP-t használni! 

Az FTP is nyíltan visz át minden információt a kliens és a 
szerver között! 

Az FTP-t használhatjuk úgy is, hogy felhasználói névvel 
és jelszóval bejelentkezünk, de használhatjuk úgy is, hogy az 
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Anonymous felhasználói névvel jelenkezünk be. Ilyenkor jelszó- 
ként az e-mail címünket kéri, amit évtizedekkel korábban még 
bátran megadtunk, ma azonban a kéretlen levelek miatt nem 
szívesen adjuk meg, anélkül is beenged, legfeljebb a , 2" karak- 
ter meglétét ellenőrzi. Természetesen anonymous FTP-vel csak 
ahhoz férünk hozzá, amit a nyilvánosságnak szántak. 


Telnet 


A Telnet programmal egy távoli gépre tudunk bejelentkezni, 
majdnem úgy, mintha előtte ülnénk. Problémák: 


e A teljes kliens-szerver kommunikáció (a jelszavas authen- 
tikáció is) titkosítás nélkül zajlik. 


. Csak karakteres felület áll rendelkezésünkre, grafikus nem. 


HyperText Transfer Protocol 


A weblapok átviteléért felelős protokoll. Igen elterjedten hasz- 
nálják, problémát okoz itt is a titkosítás hiánya. 


SSH, SCP és SFTP 


Az ssh elsődleges funkciója a biztonságos távoli bejelentkezés. 
Működése során nyilvános kulcsú kriptográfiát használva elő- 
ször egy biztonságos csatornát hoz létre a kliens és a szerver kö- 
zött, majd ezen keresztül jelszó vagy kulcs alapú authentikációt 
használ. Ha megfelelő körültekintéssel használjuk, akkor biz- 
tonságot nyújt, egyébként nem." Lehetőség van port továbbítás 
(port forwarding) használatával X session vagy fájlok átvitelére 
is. 

"Például egy szerver kulcsának elfogadása végzetes lehet, ha az nem 


a szervertől, hanem a támadótól származik. Jelszó alapú authentikáció 
esetén ilyenkor jelszavunk a támadó birtokába kerülhet. 
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Az scp parancs a Unix cp parancsának távoli gépekre tör- 
ténő kiterjesztése, ahol az átvitel biztonságosan, az ssh segít- 
ségével történik. (Természetesen az ssh-hoz teljesen hasonlóan 
csak akkor biztonságos, ha körültekintően használjuk.) 

Az sf tp is az ssh-t használja fel az átvitelre, de funkcionali- 
tásában több az scp-nél, mert nem csupán fájl átvitelre, hanem 
például könyvtár listázásra és fájl vagy könyvtár törlésére is 
használható. Ne tévesszük össze az FTPS-sel, ami SSL/TLS 
feletti FT P! 


HTTPS 


A HTTP biztonságos változata, TLS (Transport Layer Secu- 
rity) vagy SSL (Secure Socket Layer) fölött működő HTTP. Je- 
lentősége igen nagy, hiszen a mindennapi élet során egyre több 
tranzakciót hajtunk végre webes felületen keresztül. (Például: 
banki műveletek, rendszerek távoli adminisztrációja.)  Bizton- 
sági kockázatot jelent, hogy az SSL 2.0-s verziója biztonsági rést 
tartalmaz. Ezért kizárólag SSL v3.0-t vagy TLS 1.0-t használ- 
junk! 

Az ssh/scp-hez hasonlóan ez is nyilvános kulcsú kriptográ- 
fián alapul, itt egy (potenciálisan hamis) tanúsítvány elfogadása 
jelenti a legnagyobb veszélyt! További veszélyforrás, ha a bön- 
gészőnk nem ellenőrzi a CRL-eket (Certificate Revocation List 
- a visszavont tanúsítványok listája). 

A biztonsági megfontolások ismertetése sajnos meghaladja 
e jegyzet kereteit, de szeretnénk felhívni mindenkinek a figyel- 
mét, hogy a mai felhasználói szokások (tanúsítványok automati- 
kus elfogadása) mellett egy sikeres DNS elleni támadás" esetén 
a felhasználók gyakorlatilag védtelenek. A hálózati támadások- 
ról az ellenük való védekezésről ajánlott olvasmány a Hálózatok 


" A támadó eléri, hogy a kliens programok (például web böngészők) az 
általa hamisan megadott IP című gépre csatlakozzanak. 
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biztonsága tárgy jegyzete, amely jelenleg bárki számára elérhető 
1201. 


POP3S, IMAP4AS és FTPS 


A POP3, az IMAP4 és az FTP protokollok biztonságos válto- 
zatai, a biztonságot az SSL/TLS réteg nyújtja. 


5.2. TCP/IP socket interface 


A témához javasolt irodalom: [4]. Ezen kívül hasznos a Unix 
elektronikus kézikönyve (man), kiindulásként érdemes megnézni 
az IP, TCP, UDP, ICMP protokollok implementációjáról szóló 
leírást. Linux alatt": 


man 7 ip I] tcp I udp I icmp 


Unix alatt a processzek közötti kommunikációra (inter-proc- 
ess communication) több megoldás is létezik": 


. Szignálok küldése (erősen korlátozottak a lehetőségek) 
e Osztott memória (shared memory) használata 


. Socketek használata 


Ezek közül csak az utolsó használható, ha a processzek eltérő 
gépeken futnak. 

Mi is az a socket? Nem más, mint kommunikációs végpont. 
Első (kicsit sánta) közelítésként tekintsük a fájl általánosításá- 
nak. Ami a hasonlóság a kettő között, az főleg a kezelésükkel 


BA ,] jel a megszokott módon vagylagosságot jelent, tehát: man 7 ip, 
man 7 tcp, stb. Más Unix verzió alatt lehet, hogy másik kötetben találha- 
tók, például MAC OS X alatt a 4-es kötetben vannak. 

"IPC még a message gueue / semaphore megoldás is. 
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kapcsolatos: használat előtt meg kell nyitni, aztán lehet bele 
írni, lehet belőle olvasni és a végén le kell zárni. Az eltérés 
azonban nagyon jelentős. A fájl egy olyan adathalmaz, ame- 
lyet valahol tárolnak. A socket pedig az információ csere egyik 
végpontja. Ha két ilyen végpontot megfelelő módon egymás- 
hoz rendelünk, akkor amit az egyiken küldünk, a másikon azt 
fogadhatjuk; a kommunikáció természetesen mindkét irányban 
működik. A socket interfész (socket interface) pedig az a prog- 
ramozási felület, amelyen keresztül a hálózati alkalmazások el- 
érhetik a TCP/IP protocol stack szolgáltatásait. 


5.21. A TCP/IP socket interface programozása 


A továbbiakban megismerjük a socket alapú kommunikáció ele- 
meit. A TCP/IP socket interfészének programozását Unix kör- 
nyezetben, C programozási nyelven mutatjuk be." 


Socket létrehozása 


Mielőtt bármit is tennénk, létre kell hoznunk egy socket-et. Erre 
szolgál az alábbi függvény hívás: 


int socket(int domain, int type, int protocol); 


domain: a protokollcsaládot fejezi ki. 
Az 5.3. táblázatban megadtunk néhány példát a proto- 
kollcsaládra. 


type: azt fejezi ki, hogy milyen jellegű a kommunikáció. 
Számunkra a következők érdekesek: 


SOCK SIREAM megbízható kétirányú kapcsolat 
Megvalósítása TCP-vel történik. 
"Figyelem! Linux alatt a C programozás a man 2-es kötetében található, 


ha ezt nem írjuk ki, akkor esetleg más azonos nevű programok, függvények, 
stb. leírását kapjuk! 
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SXXK DGRAM datagram szolgálat 
(kapcsolatmentes, nem megbízható, a maximális cso- 
maghossz korlátozott) 
Megvalósítása UDP-vel történik. 


SXXK RAW hozzáférés a hálózatai szintű protokollhoz 


protocol: megadja, hogy milyen protokollt kell használni a 
sockethez. Általában egy adott socket típushoz csak egy 
protokoll létezik (egy protokollcsaládban), de ha esetleg 
több is, akkor ezek közül lehet vele választani. Ha csak 
egy protokoll van, akkor a protokollt kifejező szimbolikus 
konstans értéke 0, így ezt be is írhatjuk. 


return: descriptor - egy egész szám, ami azonosítja a socke- 
tet, hasonlóan, mint az open()-nel történő fájl megnyitás 
esetén. Hiba esetén a visszatérési érték: -1. 


























szimbolikus jelentés man 

konstans page 

AF UNIX, Local communication unix(7) 

AF LOCAL 

AF INET IPv4 Internet protocols ip(7) 

AF INET6 IPv6 Internet protocols 

AF IPX IPX - Novell protocols 

AF X25 ITU-T X.25 / ISO-8208 ) x25(7) 
protocol 











5.3. táblázat. Példák protokollcsaládra 


A protokollcsalád (protocol family) (más néven címcsalád: 
address family) megnevezésében az 5.3. táblázatban a szimbo- 
likus konstansoknál az ,AF " (address family) kezdetet hasz- 
náltuk. A régebbi a BSD stílusú rendszerekre jellemző a , PF " 
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" 


előtag, de a modern BSD-ben és más rendszereknél is az , AF— 
(address family) előtagot használják. 


Helyi IP cím és portszám megadása. 


Ahhoz, hogy a socketünket használni tudjuk, hozzá kell köt- 
nünk egy helyi IP címet és portot. Egy sockethez az alábbi 
függvényhívással rendelhetünk helyi IP címet és portot: 


int bind(int sockfd, struct sockaddr "my addr, 
socklen t addrlen) ; 


sockfd: socket descriptor. 


my addr: mutató egy sockaddr típusú címstruktúrára, ami 
a beállítani kívánt helyi IP címet és portszámot tartal- 
mazza. AF INET esetén ez sockaddr in típusú. (A struk- 
túra definícióját megtaláljuk a paraméterlista után.) 


addrlen: megadja a címstruktúra méretét bájtokban. 


return: hiba esetén -1, egyébként 0. 


struct sockaddr in ( 
sa family t sin family; / "address family: AF INET"/ 
u intl6 t sin port; Aport in network byte order" / 

















struct in addr sin addr; /" internet address "/ 
1 


/" Internet address: "/ 
struct in addr ( 
u int32 t s addr; /fraddress in network byte order?" / 


b 


Amint látjuk, a socket címe egy IP cím és egy port szám 
kombinációja. Az IP nem rendelkezik port számmal, azt csak 
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a fölötte levő TCP vagy UDP használja. Amint a megjegyzés 
mutatja, mind az IP cím, mind a portszám tárolása a hálózati 
bájt sorrendet követi, ami azt jelenti, hogy a legnagyobb helyi 
értékű bájt van elöl (MSB). Erre még visszatérünk 5.2.2-ben. 


Socket csatlakoztatása célcímhez 


Mivel a TCP kapcsolat orientált protokoll, nyilvánvalóan létre 
kell hozni a kapcsolatot, mielőtt kommunikálni szeretnénk. Az 
UDP kapcsolatmentes protokoll, de ekkor is beállítható egy cél- 
cím, amit így már később nem kell megadni a kommunikáció 
során. Mi a továbbiakban csak a kapcsolat orientált esettel 
(TCP) fogunk foglalkozni. 


int connect(int sockfd, const struct sockaddr " 
serv addr, socklen t addrlen) ; 


sockfd: socket descriptor. 


serv addr: mutató egy sockaddr típusú címstruktúrára, ami 
a kívánt cél IP címet és portszámot tartalmazza. AF INET 
esetén ez is sockaddr in típusú, lásd: bind(). 


addrlen: megadja a címstruktúra méretét bájtokban. 


return: ha sikerült a kapcsolódás, akkor 0, hiba esetén -1. 


Várakozás az ellenoldal csatlakozására. 


A kapcsolat létrehozása nem szimmetrikus. Mindig az egyik fél, 
a szerver várakozik a másik félre (kliens), a kliens pedig kap- 
csolódik a szerverhez a fent megismert connect() függvényhí- 
vással. 

A szerver részéről ez két függvényhívást jelent: 


int listen(int sockfd, int backlog) ; 


9.2 TCP/IP SOCKET INTERFACE 161 


sockfd: socket descriptor. 


backlog: hagyományosan a létrehozás alatt álló kapcsolatok 
(TCP 3 utas kézfogás) számának felső korlátja. Ha ezt ki- 
merítették, a szerver a további kapcsolatokat vissza fogja 
utasítani. 


A 2.2-es Linux kernelben ennek jelentését megváltoztat- 
ták, a már létrejött, de még accept()-tel el nem fogadott 
kapcsolatok maximális számát jelenti. Bővebben: man 
listen. 


return: hiba esetén -1, egyébként 0. 


int accept (int sockfd, struct sockaddr taddr, 
socklen t raddrlen) ; 


sockfd: socket descriptor. 


addr: mutató egy címstruktúrára. Ide kerül be a kapcsolódó 
fél IP címe és portszáma. 


addrlen: mutató egy kétirányú paraméterre: híváskor megadja 
a címstruktúra méretét, visszatéréskor pedig a visszaadott 
cím tényleges méretét bájtokban. 


return: siker esetén a létrejött kapcsolat eléréséhez a socket 
descriptor, hiba esetén -1. 
Adatok küldése 


A fájlba való írás függvény segítségével végezhető: A legegysze- 
rűbb: 


ssize t write(int fd, const void fbuf, size t count); 


Ez a függvény ugyanaz, amit (alacsony szintű) fájlba írásra 
is használunk. 
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fd: socket descriptor. 


buf: mutató arra a memóriaterületre, ahol az adatok találha- 
tók. Ezek, úgy ahogy vannak, átvitelre kerülnek. 


count: az átvinni kívánt bájtok száma. 


return: hiba esetén -1, egyébként az elküldött bájtok száma. 


További lehetóségeket nyújt még a writev, send, sendto, 
sendmsg függvények használata, lásd man. 


Adatok fogadása. 


ssize t read(int fd, void "buf, size t count) ; 


Ez a függvény ugyanaz, amit (alacsony szintű) fájlból való 
olvasásra is használunk. 


fd: socket descriptor. 


buf: mutató arra a memóriaterületre, ahova az adatok kerül- 
nek. 


count: a fogadni kívánt bájtok száma. 


return: hiba esetén -1l, egyébként a fogadott bájtok száma. 


További lehetóségeket nyújt még a readv, recv, recvírom, 
recvmsg függvények használata, lásd man. 
A kapcsolat bontása 


Minden socket () függvényhívással megnyitott, vagy accept () - 
tel kapott socketet le kell zárni: 


int close(int fd); 
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fd: socket descriptor. 


return: hiba esetén -1, egyébként 0. 


Fontos megjegyzés: a függvények visszatérési értékét mindig 
ellenőrizzük! 

A hálózati kommunikációval kapcsolatban példaprogramo- 
kat mutatunk be, amit a hallgatók a tárgy weblapjáról letölte- 
nek és gyakorlaton kipróbálnak. 


5.2.2. A hálózati bájtsorrend figyelembe vétele 


Több oktettből álló adatok (például egész számok) esetén szá- 
míiítógépünk architektúrájától függően eltérő lehet az adatoknak 
a memóriában való tárolása. A bájtok sorrendjét illetően két 
lehetőség van: 


LSB Least Significant Byte first" 
A legkisebb helyiértékű bájt van elöl (az alacsonyabb me- 
mória címen), így van ez például az Intel gyártmányú pro- 
cesszorok esetében. 


MSB Most Significant Byte first" 
A legnagyobb helyiértékű bájt van elöl (az alacsonyabb 
memória címen), így van ez például a Motorola gyártmá- 
nyú processzorok esetében. 


A hálózati bájtsorrend (network byte order) az MSB-t kö- 
veti, így amennyiben az általunk használt architektúra nem 
ilyen, ügyelnünk kell a konverzióra. Hordozhatónak szánt prog- 
ramok esetén úgy kell több bájtos adatokat kezelnünk, hogy 
mindkét fajta architektúrán helyesen működjön a programunk. 


4.2 


Az egész számok eltérő hosszára is figyelnünk kell! 


SAngolul gyakran hívják /ittle-endiannak, magyarul néha alvégnek. 
VAngolul gyakran hívják big-endiannak, magyarul néha felvégnek. 
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A témához kapcsolódóan felmerül egy másik érdekes kérdés 
is; ez a bájtok bitsorrendje" (például az átvitel közben: 


Isb least significant bit first 
A legkisebb helyiértékű bit van elöl. 


msb most significant bit first 
A legnagyobb helyiértékű bit van elöl. 


A bájt és bitsorrend jelzése között ezt a nagy- és kisbe- 
tűs, rendkívül logikus megkülönböztetést [11] használja. Az 
alvég/felvég problémáról bővebben: [34] 


JAR Teljesítőképesség-vizsgálat 


Számítógép-hálózatok, sőt általában kommunikációs rendszerek 
hardver és szoftver elemei, protokolljai esetén fontos azok telje- 
sítőképessége. 

Most rövid betekintést nyújtunk azokba a módszerekbe, ami- 
ket ilyen célra használni szoktak. A téma iránt mélyebben ér- 
deklődőknek ajánljuk az alábbiakban is felhasznált forrást: [32] 
valamint: [10]. 


5.3.1. . Célok, alapfogalmak 


Vizsgált rendszerként gondolhatunk akár egyetlen Ethernet há- 
lózatra vagy szerverre, de akár egy országos méretű hálózatra 
is. Nézzünk meg néhány kérdést, ami felmerülhet: 


, Mire képes a rendszer? 
. Milyen a kihasználtsága (tartaléka)? 


," El fogja-e bírni a forgalmat, ha ... ? 


Sangolul: bit endianness 
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. Milyen késleltetések, illetve késleltetésíingadozások lesz- 
nek, ha ... ? 


" Mekkora és milyen forgalmat engedhetünk még a rend- 
szerre, hogy adott minőségi paramétereket tartani tud- 
junk? 


e. Hol vannak a szűk keresztmetszetek? 
. Mit és hogyan kellene bővíteni? 


" Adott bővítés után hogyan alakulnak a jellemzők? 


Ilyen, és hasonló kérdésekre kereshetjük a választ, ha telje- 
sítőképesség vizsgálattal foglalkozunk. 
Vezessünk be néhány fogalmat: 


Felajánlott forgalom Azon csomagok összessége (időbeli el- 
oszlásukat is beleértve), melyeknek az átvitelét a forga- 
lomforrások kérik. 


Puffer ideiglenes tár (memória) a hálózati eszközökben. Eb- 
ben tárolják a csomagokat, amíg továbbítani nem tudják 
őket. Mivel a kapacitásuk véges, ezért adatvesztés történ- 
het. 


Átvitt forgalom Azon csomagok összessége (időbeli eloszlá- 
sukat is beleértve), melyeknek az átvitele megtörtént. 


Az átvitt forgalom nem egyezik meg a felajánlott forgalom- 
mal, mert a rendszer nem végtelen kapacitású. Az átvitel során 
csomagvesztés lehetséges, de ha nincs is, a várakozások miatt a 
forgalom időbeli eloszlása megváltozik. 
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A forgalom jellemzése 


A forgalmat általában nem tudjuk egyetlen számértékkel jelle- 
mezni. Különböző szempontokból más-más jellemzői fontosak. 
A forgalom néhány fontos jellemzője: 


. időegység alatt érkező / átvitt csomagok száma (főként az 
útvonalválasztók terhelését jellemzi) 


. időegység alatt érkező / átvitt bitek száma (főként az át- 
viteli csatornák / vonalak terhelését jellemzi) 


érkezési időköz eloszlás (inter-arrival time), két egymást 
követő csomag érkezési időpontjának különbsége.  Egy- 
szerű modellekben például exponenciális eloszlásúnak te- 
kintik. 


e csomaghossz eloszlás 


LON 2 


e. burstösség - a forgalom nem független az előző időszaktól 


(illetve annak forgalmától), bizonyos , csomósodás" figyel- 
hető meg. 


Forgalom jellegének leírása, jellemzőinek mérése olyan kér- 
déseket vet fel, amelyek messze meghaladják e jegyzet kere- 
teit. Most nézzünk meg két példát mért forgalmi jellemzőkre: 
az 5.4. ábrán egy kerethossz eloszlás", az 5.5. ábrán pedig egy 
érkezési időköz eloszlás látható. 

Figyeljük meg, hol vannak a kiugró értékek az 5.4. ábrán 
látható kerethossz eloszlásban, és mi ezek oka: 


"Mivel szimulációs vizsgálatainkat tipikusan hálózati szinten szoktuk 
végezni, ezért általában csomagokról beszélünk - néha még akkor is, ha 
nem hálózati szinten dolgozunk. Itt most a precizitás kedvéért említünk 
kereteket, a mérést ugyanis adatkapcsolati szinten végeztük. 
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gyakoriság 
30000 


25000 
20000 
15000 
10000 
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ü . 1 keret- 
1500 2000 hossz 


5.4. ábra. A BME FDDI gerinchálózatán 1996-ban mért forga- 
lom kerethossz statisztikája (A 67-es hossz értéknél a gyakoriság 
értéke 130000 (! körül van, ezért csonkolt.) [2] 


A nagyon rövid adategységek okozói azok az alkalmazá- 
sok, amelyek 1 karakternyi információ átvitelét igénylik, 
valamint a TCP nyugták. 


A közepes hossz kiugró aránya a hálózatos szabványokban 
keresendő: RFC 791 szerint minden IP hosztnak képesnek 
kell lennie legalább 576 oktett méretű datagramok foga- 
dására; ennél nagyobb datagramokat csak akkor szabad 


küldeni, ha a forrás hoszt meggyőződött róla, hogy a cél 
hoszt képes azt fogadni. 


A hosszú keretek pedig az Ethernet megengedett keret- 
hossza miatt akkorák, amekkorák. (Az FDDI keretmé- 
rete jóval nagyobb, de mivel gerinchálózatról van szó, a 
forgalom döntő része a reá kapcsolt Ethernet hálózatok- 
ból származik. 
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0 ERO 
0 0.001 — 0.002 — 0.003 — 0.004 — 0.005 —— 0.006 időköz 


5.5. ábra. A BME FDDI gerinchálózatán 1996-ban mért érke- 
zési időköz gyakoriságok statisztikája [2] 


Az 5.5. ábrán látható érkezési időköz eloszlásnál megfigyel- 
hető az exponenciálisra emlékeztető burkológörbe, ami azt mu- 
tatja, hogy a források Poisson folyamattal való modellezése nem 
rossz közelítés, de jól látható, hogy nem is pontos! 

Mielőtt a teljesítőképesség-vizsgálati módszerekre rátérünk, 
definiáljunk egy fontos fogalmat! 


Modell alkotás 


Definíció: A modellezés (vagy modell alkotás) olyan emberi 
tevékenység, amely során egy valóságos (létező vagy elképzelt) 
rendszernek egy valamilyen eszközkészlettel kezelhető, általá- 
ban egyszerűsített változatát hozzuk létre. A modell valamilyen 
számunkra fontos tulajdonságban hasonlít a valós rendszerre. 
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Például az áruházak kirakatában található ember alakú bá- 
buk a testi felépítés szempontjából hasonlítanak az emberre: 
hasonlóan áll rajtuk a ruha, mint az embereken. Az egér pe- 
dig bizonyos gyógyszerek hatása szempontjából tekinthető az 
ember modelljének. 

A modellezésnek a továbbiakban nagyon fontos szerepe lesz, 
két módszerünk is használni fogja. 

Kommunikációs rendszerek teljesítőképesség-vizsgálatára al- 
kalmazható módszerek: 


1. Mérés (a valóságos rendszeren való mérés) 
2. Analitikus módszer (matematikai számítás) 


3. Szimuláció (a rendszer modelljén végrehajtott kísérlet) 


Ebbe a három módszerbe tekintünk most bele. 


5.3.2. Mérés 


A legkézenfekvőbb megoldás, hogy mérjük meg, amit tudni sze- 
retnénk. Egy jól végzett méréssel (mérés sorozattal) pontos, 
hiteles adatokhoz juthatunk. Gyakran a másik két módszer ese- 
tén is szükségünk van arra, hogy a bizonyos adatokat méréssel 
szerezzünk meg. 

Azonban a mérésen kívül gyakran szükségünk van a másik 
két módszerre is. Miért? Milyen hátrányai, akadályai lehetnek 
a mérésnek? Nézzünk meg néhányat: 


" a mérés beavatkozást jelent a rendszerbe 
Ez néha problémát okozhat. Például forgalmat okoz, erő- 
forrásokat foglal, stb. 


,. a méréshez a rendszernek léteznie kell 
A rendszer megépítése drága lehet, vagy a rendszert eset- 
leg nem is lehet megvalósítani, mert például még a terve- 
zett rendszer elemei sem léteznek. 
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. a mérésnek jogi akadályai vannak 


. a mérésnek biztonsági akadályai vannak 
A mérés a mérést végzőre, a mért rendszerre, vagy a rend- 
szer adataira veszélyt jelenthetne. 


e. a mérést időben nem lehet kivitelezni 


. a mérés túl drága lenne 
Emberi erőforrások, műszerek ára miatt. 


Ilyen esetekre van két másik módszerünk. 


5.3.3. — Analitikus módszer 


Az analitikus módszer azt jelenti, hogy a vizsgált rendszer ma- 
tematikai modelljének segítségével végzünk számításokat. 
Példaként nézzük meg, hogyan lehet egy várakozás sort Mar- 
kov lánccal modellezni. A várakozási sor maga is modellje le- 
het valamilyen hálózati eszköznek, például egy routernek! Egy 
érkezési-kiszolgálási folyamatot láthatunk az 5.6. ábrán. 


A ZZTTHŰ-e 


5.6. ábra. Érkezési-kiszolgálási feladat 


Az érkezés (például egy forrás alkalmazástól a csomagok ér- 
kezése) A paraméterű Poisson folyamat szerinti. A kiszolgálás 
ideje exponenciális eloszlás szerinti u paraméterrel. A rend- 
szer állapotát a sorban álló feladatok (csomagok) száma jelenti. 
Ez minden érkezéskor eggyel nő, és minden kiszolgálás befeje- 
zésekor eggyel csökken. Kérdés lehet például, hogy állandósult 
állapotban mekkora a sorhossz várható értéke, vagy a csomagok 
hány százaléka veszik el adott (véges) méretű sor esetén. 
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A Markov lánc egy matematikai objektum, itt most elég 
annyit tudnunk róla, hogy állapotai vannak, amelyeket bizonyos 
valószínűséggel vesz fel, illetve egyik állapotából egy másik ál- 
lapotába bizonyos valószínűséggel kerül át. 

A feladatunkhoz az 5.7. ábrán látható Markov láncot ren- 
deljük. 


A. A. A 
TV u 


rendszer állapot 
A - érkezési intenzitás 
u - kiszolgálás sebessége 


5.7. ábra. Markov lánc rendelése a feladathoz 


Jelölje p, annak a valószínűségét, hogy a rendszer az f. álla- 
potban van (a sorban várakozó csomagok száma: i), formálisan: 


Pr fa rendszer az i. állapotban van) — p, 


Állandósult állapotban ugyanakkora valószínűséggel megy 
át a rendszer a 0-s állapotból az I-es állapotba, mint fordítva: 


PorA— pi: HE 
1 


A 
Di — Po— 
Rk 


" Érdeklődők bővebben olvashatnak róla: [8] 
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A 1 és 2-es állapot közötti állapot átmenetekre hasonlót felírva 


kapjuk, hogy: 
A A 
BH tes pg st 
u u 


Általános kifejezéssel: 
A n 
PnzPo (7 
j G 


Elvileg a sorhossz lehet végtelen, ekkor a valószínűségek össze- 
gére felírhatjuk, hogy: 

00 

2.971 

170 


t 
Po kiszámítható. 


Gyakorlati esetben persze a sorhossz mindig véges, jelölje N. 
Ha a puffer tele van, és új igény (csomag) érkezik, akkor az el 
fog veszni. Hasonlóképpen a valószínűségek összege: 


N 
3.071 
iz0 


J 
Pa ekkor is kiszámítható. 
A módszer segítségével megválaszolható kérdések például: 
" Mekkora a sorhossz várható értéke? 


. Mekkora puffer kell, hogy a veszteség 1 92 alatt legyen? 


Természetesen az analitikus módszer alkalmazásának is van- 
nak komoly korlátai: 
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e. az analitikus módszer pontatlan 
Mert a modell a rendszerhez képest túl sok leegyszerűsí- 
tést, elhanyagolást tartalmaz. 


e az analitikus módszer nem számolható végig 
Mert nem létezik zárt alakú megoldás, vagy mert a köze- 
lítő megoldás számításigénye sem elégíthető ki. 


Kellően nagy komplexitású rendszerek esetén az analitikus 
módszer alkalmatlan a rendszer viselkedésének kielégítő vizsgá- 
latára. 


5.3.4. Szimuláció 
Fogalmak 


A szimulációt gyakran összetévesztik az emulációval, ezért most 
mindkettőt definiáljuk: 

Definíció: A szimuláció számítógép által végrehajtható 
modellen végzett kísérlet. 

Definíció: Emulációról beszélünk, amikor valamilyen hard- 
vert vagy szoftvert más hardverrel vagy szoftverrel helyette- 
sítünk. Fekete dobozként (kívülről nézve) ugyanúgy működik, 
mint az eredeti, belső működése lehet teljesen más. 

Röviden úgy fogalmazhatjuk meg, hogy: 


e szimuláció: kísérletezés 
e emuláció: üzemszerű használat 
Lássunk mindegyikre egy-egy példát is: 


. Repülőgép szimulátor: nem tudunk vele repülni, csak a 
pilóta gyakorolhat rajta. 


174 5. FEJEZET. TOVÁBBI TÉMAKÖRÖK 


." Koprocesszor emuláció: a program is kiszámítja a szám 
négyzetgyökét, csak kicsit lassabban, esetleg más algorit- 
mussal. 


Van a szimulációval kapcsolatos másik két fogalom is, amit 
szintén össze szoktak keverni. 

A verifikáció a szimulációs modell vagy az eredmények he- 
lyességének ellenőrzését jelenti. Tipikus kérdés: , Ez a modell 
jó?" 

A validáció annak a vizsgálata, hogy a modell, illetve az 
eredmények valóban leírják-e a valóságos rendszert, amit vizs- 
gálunk. Tipikus kérdés: , Ez a jó modell?" 

Az eredmények érvényességének meghatározása is fontos. 
Milyen feltételek mellett jellemzik a rendszert az eredmények. 


A szimuláció fajtái 
Ismerjünk meg néhány fogalmat! 


Folytonos idejű rendszer állapota időben folyamatosan vál- 
tozik (például: víz áramlása egy csőben) 


Diszkrét idejű rendszer állapota diszkrét (egymástól elkülö- 
níthető) időpontokban változik 


Diszkrét idejű szimuláció A rendszer állapotváltozásai egy- 
mástól elkülöníthető időpontokban történnek (vagy úgy 
vesszük figyelembe őket). 


Eseményvezérelt szimuláció A szimuláció végrehajtása so- 
rán csak azokkal az időpontokkal foglalkozunk, amelyek- 
ben a rendszer állapotát megváltoztató esemény történik. 


Idővezérelt szimuláció A modellben az idő mindig valami- 
lyen előre meghatározott At értékkel nő, az így adódó 
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e 


időpontokban meg kell vizsgálni, hogy az előző időpont 
óta történt-e valami a rendszerben. 


A diszkrét idejű szimulációt angolul úgy nevezik, hogy: Dis- 
crete Event Simulatíon (rövidítve: DES). 


folyamatos idejű 


ző idővezérelt 
"88 


5.8. ábra. Szimuláció fajtái 


diszkrét idejű 


Szimuláció esetén különféle idő elnevezéseket szoktak hasz- 
nálni: 


e A virtuális idő (virtual time) a vizsgált rendszer modell- 
jében használt idő, éppen ezért kifejezőbb (de ritkábban 
használt) a modellidő. 


A végrehajtási idő a szimulációt végrehajtó gép valós 
idő órája által mért idő, ezt angolul úgy nevezik, hogy 
watt clock time (falióra idő). 


Eseményvezérelt diszkrét idejű szimuláció 


Az eseményvezérelt diszkrét idejű szimuláció működésében fon- 
tos szerepet játszik a jövőbeli események halmaza (Future Event 
Set - FES). Amint a neve is jelzi, a szimuláció során ebben tá- 
roljuk azokat az eseményeket, amelyekről már tudjuk, hogy be 
fognak következni. Az eseményeket időbélyeggel látjuk el; az 
időbélyeg megmutatja, hogy mely virtuális időpontban fog az 
esemény bekövetkezni. Például: 
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időbélyeg esemény leírása 
0.012 ] keret adása befejeződik 
0.018 ! keret eleje a vevőhöz megérkezik 





A szimuláció kezdetén bekerül néhány esemény a FES-be, 
majd a szimuláció során mindig a legkisebb időbélyegű ese- 
ményt vesszük ki (és ki is töröljük onnan). Az esemény kivétele 
után először is beállítjuk a modell óráját az esemény időbélyegé- 
nek az értékére, majd ,,eljátsszuk" az esemény bekövetkezését. 
Ennek során (az esemény típusától függően) különböző álla- 
potváltozók értéke megváltozhat, illetve újabb események ke- 
rülhetnek be a FES-be. Az események feldolgozásának ciklusa 
természetesen szükségszerűen befejeződik, ha a FES kiürül, de 
más feltételek miatt is megállhatunk. Az eseményvezérelt diszk- 
rét idejű szimuláció algoritmusát az alábbiakban formálisan is 
megadjuk, az algoritmusban a , MOST" a modell óráját jelenti. 


Inicializálás, azaz bizonyos események felidőzítése 
a FES-be; 

REPEAT 
Legkisebb időbélyegű esemény kivétele (és törlése) 
a FES-bői; 

MOST :- a kivett esemény időbélyege; 

Esemény feldolgozása, eközben esetleg újabb 

semény (ek) generálása (és behelyezése a 

FES-be) ; 

UNTIL (elfogytak az események) v (MOST 5 mint egy 

beolvasott határ) v (egyéb ok miatt 

meg kell állni); 












































Az algoritmus végrehajtása során az új események termé- 
szetesen csak az aktuális modell időnél (MOST) nem kisebb 
időbélyeget kaphatnak. 
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Ezt az algoritmust használják a kommunikációs rendsze- 
rek teljesítőképesség-vizsgálatára alkalmazott eseményvezérelt 
szimulátorok, mint például az OPNET Modeler [31], az OM- 
NeT-4- [30] és az ImiNet [26]. 


Teljesítőképesség-vizsgálat  szimulációval 


Mit kell tennünk, ha egy kommunikációs rendszert szimulációval 
szeretnénk vizsgálni? 

Először is elkészítjük a rendszer modelljét az alkalmazott szi- 
mulátor eszközkészletének felhasználásával. Lehet, hogy a rend- 
szerünk elemeinek a modelljét megtaláljuk a szimulátor elem- 
könyvtárában, de lehet, hogy magunknak kell megírnunk. A 
szimulátor által nyújtott módon leírjuk a rendszer topológiáját. 
(Lehet, hogy grafikus felületen összerakhatjuk a hálózatot, de 
az is lehet, hogy valamilyen szöveges topológia leíró nyelvet kell 
használnunk.) 

Modelleznünk kell a hálózatot használó alkalmazásokat, pon- 
tosabban azok forgalmát is! 

Meghatározzuk, hogy milyen feltételek mellett szeretnénk 
elvégezni a vizsgálatot, és ennek megfelelően állítjuk be a modell 
paramétereit. 

Meghatározzuk, hogy milyen jellemzők érdekesek számunk- 
ra, és ennek megfelelően állítjuk be a statisztikagyűjtést. 

Végrehajtjuk a szimulációt, közben a szimulátor statisztikát 
gyűjt az általunk kívánt jellemzőkről. 

Kiértékeljük a gyűjtött statisztikákat. Ennek alapján dönt- 
hetünk úgy, hogy a modellt vagy a terhelést módosítjuk, illetve 
szükség lehet további jellemzők megfigyelésére is. Ilyen esetek- 
ben újabb szimulációt végzünk. 

Amikor végre választ kaptunk a kérdéseinkre, akkor az ered- 
ményeinket olyan formára hozzuk, hogy az mások számára is 
emészthető legyen. Ennek részleteivel mélyebben is foglalko- 
zunk! 
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5.3.5. Mérési eredmények kezelése 


Függetlenül attól, hogy a mérési eredményeket valóságos rend- 
szeren vagy egy működtetett modellen való méréssel nyertük, 
fontos azok helyes kezelése. Először is meg kell fontolnunk a 
szükséges mérések számát. Alapelv, hogy egy mérés, nem mé- 
rési A szükséges mérések száma természetesen függ az adott 
feladattól. 


Szórás feltüntetésének fontossága 


Mérési eredményeinkből átlagot és szórást számolunk. Mivel a 
szórás számításakor nem ismerjük az elméleti várható értéket, 
ezért a tapasztalati szórás képletét használjuk, ahol a nevezőben 
a mérések számánál 1-gyel kisebb szám áll. 

Nézzünk meg egy egyszerű számpéldát arra, hogy miért fon- 
tos a szórás feltüntetése! Legyen két mennyiség: ,A" és ,,B". 
Tegyük fel, hogy mindkettőt megmértük mondjuk 10-szer, és 
az átlagra , A" esetén azt kaptuk, hogy 8,2; , B" esetén pedig 
azt, hogy 8,7. Mit mondhatunk ,A" és , B" viszonyáról? Nem 
igazán sokat! Ha viszont tudjuk, hogy például a szórás mindkét 
mennyiségnél 0,1 volt, akkor már mondhatjuk, hogy elég nagy 
valószínűséggel: ACB. Ellenben, ha például a szórás mindkét 
mennyiségnél 2 volt, akkor az esetek jelentős részében nem áll 
fenn, hogy AXB. 


Eredmények pontossága 


Az eredmények túlzott pontossággal való feltüntetése helytelen. 
Tegyük fel, hogy egy mérés eredményeként azt kaptuk, hogy 
egy mennyiség mért értékeinek átlaga: 8.4786; szórása pedig: 
1,2345. Ebben az esetben bátran kerekítsük a várható értéket 
8,5-re, a szórást pedig 1,2-re! 
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5.4. . Eredmények megjelenítése 


Függetlenül attól, hogy az eredményeket milyen módon kaptuk 
(például méréssel, számítással vagy akár szimulációval), gyak- 
ran szükségünk van arra, hogy eredményeinket másoknak bemu- 
tassuk. Az alábbiakban közölt szempontok hasznosak lehetnek 
mind papír alapú művek, mind szóbeli előadásokat támogató, 
projektorral vetített anyagok készítésénél. 

A következőkben anyagok teljes átvételével is támaszkodunk 
[32] forrásra, amely viszont felhasználta a következőt: [10]. 


5.4.1. — Általános szempontok 


Egy ábrának vannak alapvető alaki kellékei, mint például grafi- 
konok esetén: 


e cím (képaláírás): mit látunk az ábrán 
. tengelyfeliratok, mértékegységek 


" tengelyeken egységek bejelölése; derüljön ki, hogy lineáris 
vagy logaritmikus skálát használunk 


. ha több jellemzőt is ábrázolunk: melyik grafikon mit je- 
lent 


e. hasznos a nevezetes értékek (min/max hely, inflexiós pont, 
stb.) koordinátáinak feltüntetése. 


Példaként nézzünk meg egy grafikont, ahol szerepelnek a 
szükséges alaki kellékek: 5.9. ábra. 
Néhány további általános szempont, jó tanács: 


, A grafikus megjelenítés jobban áttekinthető, mint a táb- 
lázatos, de nem helyettesíti azt. 
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R-100£2-os elfenálláson átfolyó 
Ilma] áram a feszültség függvényében 





1 2 10 UV] 


zo zh 


5.9. ábra. Szemléltető ábra 


. Az ábrába a maximális mennyiségű információt vigyük 
be! 


. Ugyanakkor az olvasótól minimális erőfeszítést követeljen 
meg az eredmények áttekintése! 


e. Az eredmény érvényességére vonatkozó adatok is ott sze- 
repeljenek (az ábrán, vagy az ábra címében)! 


, A grafikonok jelentését külön magyarázzuk meg, vagy még 
jobb, ha az ábrába írjuk: 5.10. ábra! 


vaj 


. Adott független változó függvényében akár eltérő függő 
változókat is ábrázolhatunk egy ábrában, de ne legyen az 
y tengelyen sok skála, legfeljebb kettő! (5.11. ábra) 


Ne kössük össze a nem folytonos dolgokat! (5.12. ábra) 
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5.10. ábra. Jelmagyarázat és ami még jobb 


IImAJ PIWI] 
100 1 
20 02 
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5.11. ábra. Az y tengelyen legfeljebb két skála legyen! 


Erdemes színeket használni, ha erre lehetőség van! 


Színválasztás: háttér és szöveg (rajz) fényereje erősen el- 
térő legyen! Például sötét háttéren világos ábra vagy for- 
dítva. (Különben projektoros kivetítésnél nem lesz jól lát- 
ható.) 
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5.12. ábra. Ne kössünk össze nem folytonos dolgokat! 


" Összeillő színeket válasszunk! (Színkörbe szabályos sok- 
szöget írunk.) 


" Ügyeljünk arra, hogy fekete-fehér nyomtatás / fénymáso- 
lás után is értelmezhető maradjon a munkánk! (Például 


b. 


eltérő vonalvastagság, szaggatott vonal, stb.) 


5.4.2. — Ábrázolási módok 


Az ábrázolandó mennyiség jellegétől függően más-más módot 
választunk a megjelenítésre. Ezek közül mutatunk be néhányat. 


Függvény grafikonja 


Amennyiben az ábrázolni kívánt függvény értelmezési tartomá- 
nya és értékkészlete (a vizsgált tartományban) folytonos, ak- 
kor az 5.9. ábra szerint ábrázolhatjuk. Ha a függvény képlet 
formájában adott, az ábrázolás nem okoz gondot. Ha viszont 
mérési eredményeket ábrázolunk, akkor csak véges, esetleg kis 
számú (például 10db) független változó értékre van mért érté- 
künk. Ebben az esetben alkalmazhatunk törtvonalas közelítést, 
vagy illeszthetünk rá görbét. Ilyenkor hasznos lehet a mérési 
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pontokban kapott értékek megkülönböztetése a többi értéktől. 
Erre látunk példát az 5.13. ábrán. 

További hasznos eszköz lehet, ha a mért értékeknél feltün- 
tetünk valamilyen (például 9099-os) konfidencia intervallumot 
is, illetve amennyiben (például az eloszlás ismeretének hiányá- 
ban) ezt nem tudjuk megtenni, akkor értelmes lehet a mérési 
pontokba olyan függőleges szakaszt rajzolni, aminek a közepe 
a mért (átlag)értékre illeszkedik, alsó végénél a függő változó 
értéke átlag-szórás, felső végénél pedig átlagtszórás. Ehhez 
természetesen minden mérési pontban (adott független változó 
érték mellett) megfelelő számú mérést kell végeznünk. 


R-100£-os ellenálláson átfolyó 
IImA] áram a feszültség függvényében 
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5.13. ábra. Folytonos függvény közelítése mért értékek alapján 


Amennyiben a függvény értelmezési tartománya nem foly- 
tonos, akkor a mért értékeket ábrázoló pontokat nem szabad 
összekötni, mert nincs valóságos tartalmuk, amint az 5.12. áb- 
rán láttuk. Erre mutatunk az alábbiakban egy másik megoldást 
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is, ami egy speciális esetben használható. 


Oszlopdiagram 


Az oszlopdiagramot olyan függvényeknél célszerű alkalmazni, 
amikor az értelmezési tartomány nem folytonos, a független 
változó egymástól egyenlő távolságban található, viszonylag kis 
számú értéket vesz fel. (5.14. ábra) 


Linux felhasználók számának 


A 
(Ezer fő] 57 e 53 
növekedése Magyarországon. 


707 








) 2003 2004 2005 lév] 


5.14. ábra. Példa oszlopdiagramra (nem valós adatok) 


Kördiagram 


A kördiagramot százalékos megoszlás ábrázolására használhat- 
juk. Az egész kör jelenti a 10099-ot. (5.15.) 


Venn-diagram 


Halmazok és a köztük levő relációk ábrázolására használhatjuk 
a Venn-diagramot. (5.16. ábra) 
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5.15. ábra. — A feltelepített operációs rendszerek megoszlása 
2015-ben Magyarországon, (nem valós adatok) 






angol nyelvet 
tanul 







német nyelvet 
tanul 







KANBKÉT ei 


francia nyelvet 
tanul 






5.16. ábra. Példa halmazok közötti relációk ábrázolására (nem 
valós adatok) 


Gantt-ábra 


A Gantt-ábra segítségével ábrázolhatjuk erőforrások kihasznált- 
ságát az időbeli átlapolódások figyelembe vételével. (5.17. ábra) 
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5.17. ábra. Gantt-ábra 


Kiviat-gráf 


A Kiviat-gráfot" százalékos értékek ábrázolására szokták alkal- 
mazni. Az ábrát úgy készítjük el, hogy egy körbe (egyenletes 
elosztásban) berajzolunk a vizsgált jellemzők számának megfe- 
lelő számú sugarat, majd ezekre a kör középpontjától kiindulva 
bejelöljük az egyes jellemzők százalékos értékét (092: kör közép- 
pontja, 10099: körvonal), majd a bejelölt pontokat összekötjük 
a szomszédaikkal. Az összekötés célja folthatás elérése. 

Megtehetjük, hogy a kör mentén váltakozva HB (Higher is 
Better - minél nagyobb annál jobb) és LB (Lower is Better 
- minél kisebb, annál jobb) értékeket helyezünk el. Ekkor az 
optimális ábra egy sokágú csillag lesz. 

Egymás mellé helyezhetünk korrelált, illetve nem korrelált 
mennyiségeket is. 

Az 5.18. ábrán egy Kiviat-gráfot látunk, ahol az egyes meny- 
nyiségek jelentése a következő: 


1. CPU foglalt 


2. csak a CPU foglalt 


"SA Kiviat-gráfot radar-gráfnak is szokták nevezni. 
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5.18. ábra. Példa Kiviat-gráfra 


3. CPU és csatorna átlapolt 

4. csak csatorna foglalt 

5. bármely csatorna foglalt 

6. CPU vár 

7. CPU felhasználói programot hajt végre 


8. CPU supervisor állapotban 


A folt alakjából nagyon gyorsan megállapíthatók a rendszer 
bizonyos tulajdonságai. Esetünkben például van néhány tipikus 
alak, például: 


. főleg a CPU-t használja (5.19. ábra) 
. főleg a csatornát használja (5.20. ábra) 


A diagramot több szintűre is lehet rajzolni. Például memó- 
ria méretet növelem.(5.21. ábra) 
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5.20. ábra. A csatorna használata dominál 


Hisztogram 


Eloszlásokat szemléletesen jellemezhetünk a valószínűségi sű- 
rűségfüggvényükkel. Amennyiben az eredményeink megfigye- 
lésből (teljesen mindegy, hogy egy valóságos rendszeren való 
mérésekkel vagy szimulációból) származnak, tipikus, hogy az 
eloszlás jellemzésére egy adott számosságú minta áll rendelke- 
zésünkre. A minta elemeinek egyenkénti megjelenítésénél sok 
esetben jobb megoldás, ha a mintákból hisztogramot készítünk. 
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5.21. ábra. Többszintű Kiviat-gráf. 


Hisztogram készítéséhez a megfigyelések lehetséges érték- 
készletét diszjunkt, és az értékkészletet teljesen lefedő inter- 
vallumokra bontjuk. Ezeket az intervallumokat celláknak ne- 
vezzük. A legegyszerűbb esetben a cellák szélessége azonos. Ez 
nem mindig célszerű választás, sokszor jobb (az eloszlást ponto- 
sabban jellemző) eredményt kaphatunk, ha az eloszlás közelítő 
ismerete alapján a cellahatárokat úgy választjuk meg, hogy az 
egyes cellákba eső megfigyelések száma közel egyenlő legyen. A 
hisztogram celláit oszlopokkal (téglalapokkal) ábrázoljuk úgy, 
hogy az oszlop alapja a hisztogram celláját jelentő szakasz (a 
cella szélességét jelölje d), magassága pedig Ah. Az i. cella esetén: 


zt 
og; 

ahol: 

hi — az i. cellát ábrázoló oszlop magassága 


rij z az iz. celllíába eső elemek száma 
di 5 az iz. adíta szélessége 


Lássunk egy példát: 5.22. ábra. 
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5.22. ábra. Példa hisztogramra 


Ha egy hisztogramot normálunk, azaz a cellák magasságát 
elosztjuk az összes megfigyelés számával, akkor hisztogram te- 
rülete 1 lesz: megkapjuk a valószínűségi sűrűségfüggvény" kö- 
zelítését. 


Két változós függvény ábrázolása felülettel 


Amennyiben egy két változós függvényt szeretnénk ábrázolni, 
azt megtehetjük például úgy, hogy a független változóit egy 
négyzetháló mentén tekintjük, és ezekre ábrázoljuk a függvény 
értékét: Ilyenre látunk példát az 5.23. ábrán. 


5.4.3. — Trükkök 


Az alábbiakban bemutatott trükkök egyrészt használhatók a 
mondanivalónk hangsúlyozására, másrészt viszont vissza is le- 
het velük élni; alkalmasak az olvasó megtévesztésére is! Ez utób- 
bit semmiképpen sem javasoljuk, hanem inkább arra bátorítjuk 
e jegyzet olvasóit, hogy mérnöki munkájuk eredményének be- 
mutatása során legyenek becsületesek! Mégis hasznos ezeknek 


f(x), angolul: PDF - Probability Density Function, az integrálja pedig 
megadja az eloszlás függvényt /F(x), angolul: CDF - Cumulative Density 
Function 
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5.23. ábra. Példa felület ábrázolására 


a trükköknek az ismerete, mert sajnos mind a mérnöki munka 
során, mind a hétköznapi életben (például reklámok, politikai 
hirdetések) találkozhatunk ezekkel a trükkökkel; ismerjük fel 


óket, és ne hagyjuk magunkat becsapni! 


. Ha azt szeretnénk hangsúlyozni, hogy minden majdnem 
10099-os, akkor az 5.24. ábra , a" részében látható módon a 
skála 092-tól 10092-ig terjedjen, ha a különbséget kívánjuk 
hangsúlyozni, akkor az ábra , b" részében látható módon a 
skálát nem 092-tól célszerű indítani. Így a különbségek a 
valóságosnál nagyobbnak tűnnek!" A különbséget hang- 
súlyozza az 5.24. ábra , c" része is, ahol azt ábrázoltuk, 


hogy mennyi kellene a 100938-hoz." 
. Ha összehasonításnál egyenlő szélességű oszlopok helyett 


"Ez teljesen becsületes is lehet: alkalmas kicsi, de jelentős különbségek 
kimutatására, de felhasználható lényegtelen különbségek felnagyítására is. 
Azt, hogy a különbség lényeges vagy sem, a műszaki életben sok esetben 
el lehet dönteni, a hétköznapi életben ez sokkal nehezebb kérdés ... 

" Ennek is lehet érdemi jelentése, például: mennyi a szabad kapacitás. 
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5.24. ábra. Különbségek elfedése vagy kinagyítása 


(amelyeknek a magassága lenne arányos az ábrázolandó 
mennyiséggel) az ábrázolandó mennyiséggel lineáris mé- 
retben arányos, két dimenziós ábrákat használunk; az már 
kifejezetten becsapás, ugyanis a szemünk területet érzé- 
kel! így például egy kétszeres arány négyszeresnek látszik: 
5.25 ábra. 


[608 





5.25. ábra. A szemünk területet érzékel 


A relatív jellemzők használata kifejezetten alkalmas a be- 
csapásra. (Mottó: ,AA statisztika a számok segítségével 
elkövetett hazudozás.") Például: 


- . kerekek száma / ütemek száma —- a kétütemű Tra- 
bant a legjobb autó 

- egy főre jutó űrhajósok száma —- Magyarország az 
űrhajózásban az élen áll 


5.4. 
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Többdimenziós ábrán (két független és egy függő változó 
esetén) például az oszlopok elhelyezkedése is kihasznál- 
ható: 5.26. ábra. Az ábrán a Számítógép-hálózatok tan- 
tárgyból tett első vizsga sikerességének valószínűsége lát- 
ható a hallgatók előadás és gyakorlat látogatási hajlandó- 
ságának függvényében. Első ránézésre azok a hallgatók, 
akik mindkét helyre becsülettel járnak, toronymagasan ki- 
ugranak a többiek közül. Trükk: az ő oszlopuk eleve ma- 
gasabban kezdődik! 





























5.26. ábra. Az első vizsga sikerességének valószínűsége a rend- 
szeres előadásra és a gyakorlatra járás függvényében. 
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Az 5.27. ábrán a perspektivikus ábrázolást használjuk a 
(túl hangsúlyozásra. A magasabb oszlopok így széleseb- 
bek is (és a szemünk területet érzékel), ráadásul a függő 
változó tengelyének a skálája nem lineáris: a magasabb 


oszlopok még magasabbnak látszanak! 





5.27. ábra. Perspektíva kihasználása 


A. Függelék 


Unix bevezető 


A tárgy gyakorlatain Linux operációs rendszert használunk, eh- 
hez szükséges az alapvető Unix" parancsok ismerete. A gyakor- 
latokon használt Debian GNU/Linux egy GPL licensz [22] alatt 
használható szabad?" operációs rendszer. 

Bővebb ismertetésre e jegyzet keretei nem nyújtanak lehető- 
séget, ezért az érdeklődő hallgatóknak javasoljuk, a távközlés- 
informatika szakirányos hallgatók pedig tekintsék kötelezőnek 
az alapvető Unix felhasználói ismereteket nyújtó [16] vagy más 
hasonló forrás tanulmányozását. További, kifejezetten Linux 
specifikus ismereteket nyújtó ajánlott forrás: [12]. 


A.1. —Alapismeretek 


A Unix egy többfeladatos (multitasking) operációs rendszer, ami 
azt jelenti, hogy egyszerre több programot is futtathatunk." 


JA UNIX (csupa nagy betűvel) bejegyzett márkanév, Unixnak nevezzük 
az összes UNIX-szerű operációs rendszert. 
? A szabad szoftverekről bővebben: [21] 

JA programok nem biztos, hogy tényleg egyidejűleg futnak, lehet, hogy 
csupán az operációs rendszer váltakozva futtatja őket. 
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Emiatt szükséges a programok esetleges káros (hibás vagy rossz 
szándékú) működésétől védenünk a többi programot, az operá- 
ciós rendszert, sőt a hardvert is. A programok csak a rendel- 
kezésükre bocsátott memória területet használhatják, minden 
szolgáltatást operációs rendszer (kernel) függvényhívásokon ke- 
resztül vehetnek igénybe, közvetlenül a hardverhez nem férhet- 
nek hozzá. Ehhez természetesen hardver támogatás szükséges, 
a processzornak legalább két privilegizációs szintet kell támo- 
gatnia: a kernel privilegizált módban fut, míg a felhasználók 
programjai az alap szinten futnak. 


A Unix többfelhasználós (multi-user) operációs rendszer is, 
ami azt jelenti, hogy egy gépen több felhasználó is dolgozhat. 
Az egyes felhasználók adatait is védeni kell egymástól, erre szol- 
gálnak a fájlrendszerrel kapcsolatos védelmi mechanizmusok. 
A rendszer adminisztrálásához szükség van olyan felhasználóra 
(super user) aki mindenhez hozzáfér. Unix alatt a super usert 
rootnak hívjuk. 


Ahhoz, hogy valaki egy Unix rendszeren dolgozhasson, elő- 
ször be kell jelentkeznie a rendszerbe.  Bejelentkezni valamely 
előzőleg létrehozott felhasználói néven (login name) lehet, a fel- 
használó a jelszó (password) megadásával bizonyítja a személy- 


azonosságát. 


A.2. — Fájlrendszer 


A Unix a DOS/Windows rendszerekkel ellentétben nem használ 
meghajtó jelöléseket (mint ,A:" vagy ,, C:"), hanem egyetlen fájl- 
rendszer megfelelő pontjaira (alkönyvtár nevek alá) kapcsolja fel 
az egyes köteteket. 
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A. 2.1. Könyvtárszerkezet 


A könyvtár rendszer kiindulási pontját (root vagy gyökér könyv- 
tár) a "/" jellel jelöljük. Az A.l. ábra egy fipikus Unix könyv- 
társzerkezetef mutat. 


bin mp etc dev usr home var  mnt proc. lib — sbin — boot 


lencse — jonci — gecko 


lencse  jonci — gecko 


A.I. ábra. Tipikus Unix könyvtárszerkezet 


A szokásosan alkalmazott alkönyvtárak közül megadjuk né- 
hánynak a funkcióját. 


/bin Az alapvető, minden felhasználó számára fontos paran- 
csok (például: Is, cp, cat) találhatók ebben. 


/boot Az operációs rendszer indulásával kapcsolatos fájlok ta- 
lálhatók benne. 


/dev Az eszközfájlokat tartalmazza. 


/etc A rendszer adminisztrálásával kapcsolatos dolgokat (pél- 
dául konfigurációs fájlokat) tartalmazza. 


/home A rendszerre felvett felhasználók könyvtárait tartal- 
mazza. 


/lib A dinamikusan szerkesztett programkönyvtárak helye. 


" A különféle Unix rendszerekben hasonló alap könyvtárszerkezetet hasz- 
nálnak, de vannak eltérések is. További információ: [35] 


198 A. FÜGGELÉK. UNIX BEVEZETŐ 


/mnt Ide szokás felkapcsolni az ideiglenesen felcsatolt kötete- 
ket. 


/proc Virtuális fájlrendszer: fájlként láthatjuk a kernel belső 
dolgait. 


/root A rendszergazda home könyvtára. 


/sbin A rendszer adminisztrálására szolgáló parancsokat (pél- 
dául: fdisk, init) tartalmaz. 


/tmp Bárki által írható könyvtár, az ideiglenes fájlok tárolá- 
sára szolgál. 


/usr További alkönyvtárakban a felhasználói programokat tar- 
talmazza. 


/var További alkönyvtárakban olyan dolgokat tartalmaz, ame- 
lyek tipikusan változni szoktak, például nyomtatási sorok, 
levelesládák, naplófájlok, stb. 


A különböző eltávolítható média eszközöket (például: opti- 
kai vagy USB flash drive) újabban nem a /mnt, hanem a /media 
könyvtár alá szokták felkapcsolni. 

Hétféle könyvtárbejegyzés lehetséges: 


directory könyvtár, amely a könyvtárbejegyzés típusok bár- 
melyikéből tartalmazhat bejegyzéseket 


file normál állomány/fájl, amely adatoknak egy névvel azono- 
sított halmaza 


block device speciális eszközfájl, a Unix minden hardver esz- 
közt (perifériát) device-ként azonosít, ezek között vannak 
blokkos átvitelt használók 


character device karakterenkénti átvitelt használó periféria 
azonosítására szolgáló speciális eszközfájl 
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symbolic link szimbolikus link, amely egy másik könyvtárbe- 
jegyzésre mutat 


socket socket, lásd: 5.2. 
pipe névvel rendelkező csővezeték (named pipe) 
Néhány jellegzetes Linux periféria név : 
/dev/hda Az első (primary master) IDE-s merevlemez egysé- 


get jelöli, a továbbiak: hdb, hdc, stb. 


/dev/fdO Az első hajlékonylemez-meghajtót jelöli. A követ- 
kező: fdl. 


/dev/sda Az első SCSI merevlemez egységet jelöli, a továb- 
biak: sdb, sdc, stb. SCSI emuláció esetén ilyen nevet 
kapnak például az USB flash drive-ok, SATA merevleme- 
zek is. 


/dev/ttyO ttyl, tty2, stb. a billentyűzet neve. 
/dev/psaux A ps2-es egér neve. 


/dev/null Végtelen kapacitású nyelő: nyom nélkül eltünteti a 
bele irányított kimenetet. 


A.2.2. — Fájlrendszerrel kapcsolatos parancsok 


Az alapvető Linux felhasználói jártasság megszerzése a labor- 
gyakorlatokon történik, itt csak egy rövid összefoglalást adunk. 
A leírásban a , Cr" és , 2" jelek úgynevezett metanyelvi zárójelek, 
a közöttük levő szöveg azt jelenti, hogy oda mit kell írni a pa- 
rancs kiadásakor. A , c" és , 2" jeleket természetesen nem kell, 
sőt nem szabad begépelni, mert akkor egészen mást jelentenek 
a parancsok! 


"Felhívjuk az olvasó figyelmét, hogy ezek kifejezetten a Linuxra jellem- 
zőek, más Unix rendszerek más konvenciót használnak! 
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Is könyvtár listázása 

Is -a könyvtár listázása a rejtett fájlokkal együtt 
Is -I könyvtár listázása, az attribútumokat is kiírja 
cd Cdirectory2 belépés a megadott könyvtárba 


cd A parancsot argumentum nélkül kiadva a felhasználó saját 
home könyvtárába jut. 


pwd aktuális munkakönyvtár (working directory) nevének ki- 
írása 


mkdir Cdirectory2 könyvtár létrehozása 


rmdir Cdirectory2 könyvtár törlése, csak üres könyvtár ese- 
tén használható 


rm Cfájlnév vagy fájlnevek- fájl(ok) törlése 


b. 


rm -r Cdirectory2 könyvtár rekurzív törlése a benne lévő 
fájlokkal, alkönyvtárakkal együtt 


cat fájl tartalmának kiírása 

cp dCforrás fájb dCcél fáj- fájl másolása 

cp Cíbrrás fájlokz Ccél könyvtár: fájlok másolása 
mv Cforrász Ccél- fájl(ok), könyvtár(ak) mozgatása 


du lemezhasználat: könyvtár és alkönyvtárainak helyfoglalását 
adja meg 


df lemezhasználat: egyes kötetek kihasználtságát (teljes, sza- 
bad, foglalt terület és i-node-ok) adja meg 


guota a felhasználó által használható és felhasznált terület ki- 
jelzése 
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A.2.3. — Jogosultságok és kezelésük 


Minden fájlra és könyvtárra a jogok három csoportja vonat- 
kozik. A jogokat kilenc biten tároljuk. Az első három bit 
adja meg a tulajdonosra (owner) vonatkozókat, a negyediktől 
a hatodikig a fájl csoporttulajdonosaként beállított csoportba" 
(group) tartozó felhasználók jogait, az utolsó három pedig az 
összes többi felhasználó (world) jogait adja meg. Egy fájl- 
nál a bithármasok rendre meghatározzák az írásra, olvasásra 
és a végrehajtásra való jogokat (read, write, execute: "Twx"). 
Egy könyvtárnál pedig meghatározzák a listázásra, módosításra 
(benne fájlok, könyvtárak létrehozása, törlése) és a navigálásra 
(a benne lévő fájlok, könyvtárak elérése) való jogokat. Tekint- 
sük például egy fájl esetén az A.l. táblázatban megadott jo- 
gokat. Ezen jogok alapján a tulajdonos jogosult a fájlt írni 
és olvasni, a csoporttulajdonosként megadott csoportba tartozó 
felhasználók jogosultak a fájlt olvasni, ezen kívül senki másnak 
semmi más joga nincs rá. 


szimbolikus Ír w xír w xír w x 
bináris 1 1 0]/1 0 0jfj0 0 0 
oktális 6 4 0 


A.l. táblázat. Példa jogosultságokra 


A jogosultságok beállításával kapcsolatos alapvető Unix pa- 
rancsok: 


chmod Cxjogok- dCfájlnév- jogok beállítása (A jogokat ok- 
tálisan adjuk meg.) 


"Valójában ennél többön, de az meghaladja e bevezető kereteit. 

" A Unixban a felhasználókat csoportokba soroljuk, minden felhaszná- 
lónak van egy elsődleges csoportja, ezen kívül tagja lehet még további 
csoportoknak is. 
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chown Cwxusername- dAfájl vagy könyvtár neve- tulaj- 
donos megadása. 


chgrp XCgroup- dfájl vagy könyvtár neve- csoporttu- 
lajdonos megadása 


A.3. Hálózat kezelése 
Alapvető Unix parancsok: 


ifconfig Argumentum nélkül az aktív hálózati interfészeket lis- 
tázza ki a legfontosabb adataikkal együtt. Paraméterezé- 
sét egy példával mutatjuk be (külön). 


route Argumentum nélkül kiírja a kernel routing táblázatának 
bejegyzéseit. 


route add default gw Cdefault gateway2- Beállítja az 
alapértelmezett átjárót." 


netstat Részletes információt ad a fennálló (létrehozás vagy 
lebontás alatt álló) hálózati kapcsolatokról. 


A ping és a traceroute parancsokat már korábban (3.4.3) 
ismertettük. 

A laborgyakorlatokon használt gépekben két-két Ethernet 
hálózati kártya található, ezeket a Linux ethO-val és ethl-gyel 
jelöli. Most példaként az ethO interfészt fogjuk beállítani. Le- 
gyen az IP címe: 192.168.100.41, a netmask: 255.255.255.224, 
az alapértelmezett átjáró: 192.168.100.33 


ifconfig etho 192.168.100.41 NM 
netmask 255.255.255.224 4 





" Az add CXnetx gw Cgateway: forma Linux specifikus, máshol a gw 
szócska nem kell! 
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broadcast 192.168.100.63 up 
route add default gw 192.168.100.33 


Figyelem! A fentiekben összesen két (! parancsot adtunk 
ki, ugyanis a sor végi backslash (,V) azt jelenti, hogy a parancs 
a következő sorban folytatódik! Az első paranccsal értelem- 
szerűen beállítottuk a gépünk IP címét és hálózati maszkját, 
valamit megadtuk a broadcast címet (az ifconfig igényli), vé- 
gül aktivizáltuk az interfészt az up-pal. A második paranccsal 
beállítottuk az alapértelmezett átjárót. 

Ezek után máris tesztelhetjük gépünk hálózati kapcsolatát 
a ping paranccsal. 

Teljes értékű használathoz szükségünk van még legalább egy 
névkiszolgáló IP címének beállításához. Ha a névkiszolgáló a 
193.224.130.161 IP címen érhető el, ezt beállíthatjuk az alábbi 
paranccsal: 


echo "nameserver 193.224.130.161" xx /etc/resolv.conf 


A.4.  Programfejlesztés 
Alapvető Unix parancsok: 


gcc dforrás fájl nevez C vagy C1- 1 forráskód lefordítása, 
az eredmény out" fájlba kerül. 


gcc Cforrás fájl nevez -o XxCprogram neve: C / Ca - 
forráskód fordítása úgy, hogy a program neve a megadott 
név legyen. 


gcc Cforrás fájl neve- -g C/ C1t 1 forráskód fordítása úgy, 
hogy a program nyomon követhető legyen gdb-vel, az ered- 
mény az ,,a.out" fájlba kerül, de kombinálható az előzővel. 


gdb CXprogram neve: Program nyomkövetése gdb-vel. 
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Nyomkövetés gdb-vel 

1 Csor száma: forráskód sorainak listázása 
b Csor száma- töréspont megadása 

d dCtöréspont száma? töréspont törlése 

r futtatás 

c futás folytatása 


n egy lépés végrehajtása (a függvényeket egy utasításnak te- 
kinti, azaz egy lépésben végrehajtja) 


s egy lépés végrehajtása (függvényben csak egyet lép) 
p Sváltozó neve: a változó értékének kiírása 
g kilépés 


set args C1. arguaumentum- X2. argumentum: a prog- 
ram parancssorbeli paramétereinek megadása 


A.5. — Egyéb szükséges Unix parancsok 


echo Cargumentum?: Kiírja az argumentumát, és az eset- 


leg benne szereplő dollár jelet követő környezeti változó 
értékét. (például: echo $TERM) 


ps aux Kilistázza a futó programokat. Unix alatt minden elin- 
dított program egy processzként fut, és kap egy azonosító 
számot (process ID), a programra ezzel számmal tudunk 


b 


hivatkozni a későbbiekben. 


kill process ID- Leállítja az adott programot, pontosab- 
ban egy TERM szignált küld, amit a program kezel, eset- 
leg nem hajlandó a futást befejezni. 
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kill -9 xprocess ID- Mindenképpen leállítja a programot. 
(KILL szignál) 


kill -SEGV Xprocess ID-2 Leállítja a programot és egy core 
fájlban eltárolja annak memóriaképét, amely segítségével 
később folytatható a futtatás (például gdb-vel). 


more dCfájl név- Kiírja a képernyőre a fájl tartalmát, amíg 
kifér a képernyőre és vár egy billentyű leütésig, majd foly- 
tatja a kiírást. 


less Cfájl név- Kiírja a képernyőre a fájl tartalmát, amíg 
kifér a képenyőre, majd fel és le is lehet görgetni a doku- 
mentumot. (Kilépni a g billentyű leütésével lehet.) 


£Xprogram neve2x 2 cki-fájlí ca cCbe-fájl? Átirányítás. 
A program kimenetét a megadott fájlba írja, bemenetét 
pedig a másik megadott fájlból veszi. A ,,2" jel használa- 
tával az esetlegesen már létező fájl tartalmát felülírja, a 
, 2)" jel esetén viszont a fájlhoz hozzáír (append). 


CX1. program neve: ] 2. program neve: Csővezeték. 
Az első program kimenetét a második program bemene- 
tére irányítja. 


sort Lexikografikus rendezés a bemenet soraira. Argumentum 
nélkül a standard inputról dolgozik, de megadható fájlnév 
is. A ,,-T" opcióval csökkenő sorrendbe rendez. 


difi" C1. fájl nevez €2. fájl neve: Fájlok összehasonlítá- 
sa. Szöveges fájloknál a különbséget írja ki. Bináris fáj- 
loknál csak az eltérés tényét állapítja meg. 


man CUnix parancs, C függvény, stb.2 On-line Unix ké- 
zikönyv. Leírást ad arról, amiről kértük. Mivel a kézi- 
könyv kötetekből áll, esetleg szükséges lehet a kötet szá- 
mának a megadása is, például: man 2 printf, ellenkező 
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esetben előfordulhat, hogy egy másik, ugyanolyan nevű 
parancs leírását kapjuk! 


Érdeklődő hallgatóinknak javasoljuk valamelyik ajánlott for- 
rás ([16] vagy [12]) olvasását és a benne szereplők kipróbálását. 
Jó munkát! 
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